home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 8_4_04.tro < prev    next >
Text File  |  1991-12-22  |  93KB  |  4,048 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright (~c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v'|.5i'
  22. .sp 1P
  23. .ce 1000
  24. SECTION\ 2
  25. .ce 0
  26. .sp 1P
  27. .ce 1000
  28. \fBSERVICE\ DEFINITIONS\fR 
  29. .ce 0
  30. .sp 1P
  31. .sp 2P
  32. .LP
  33. \fBRecommendation\ X.210\fR 
  34. .RT
  35. .sp 2P
  36. .ce 1000
  37. \fBOPEN\ SYSTEMS\ INTERCONNECTION\fR 
  38. .EF '%    Fascicle\ VIII.4\ \(em\ Rec.\ X.210''
  39. .OF '''Fascicle\ VIII.4\ \(em\ Rec.\ X.210    %'
  40. .ce 0
  41. .sp 1P
  42. .ce 1000
  43. \fBLAYER\ SERVICE\ DEFINITION\fR \fB\ CONVENTIONS\fR 
  44. .FS
  45. Recommendation\ X.210
  46. and ISO\ TR\ 8509, [Information processing systems\ \(em\ Open Systems
  47. Interconnection\ \(em\ Service conventions] were developed in close collaboration 
  48. and are technically aligned, except for the differences noted in
  49. Appendix\ II.
  50. .FE
  51. .ce 0
  52. .sp 1P
  53. .ce 1000
  54. \fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR 
  55. .sp 9p
  56. .RT
  57. .ce 0
  58. .sp 1P
  59. .sp 2P
  60. .LP
  61.     The CCITT,
  62. .sp 1P
  63. .RT
  64. .sp 1P
  65. .LP
  66. \fIconsidering\fR 
  67. .sp 9p
  68. .RT
  69. .PP
  70. (a)
  71. that Recommendation X.200 provides a Reference Model
  72. which separates the functions of inter\(hyprocess communications into seven
  73. layers;
  74. .PP
  75. (b)
  76. that the layer services developed for these seven
  77. layers of function will generally result in separate Recommendations;
  78. .PP
  79. (c)
  80. that there is a need for the resulting Recommendations   to be a coherent set,
  81. .sp 1P
  82. .LP
  83. \fIunanimously recommends\fR 
  84. .sp 9p
  85. .RT
  86. .PP
  87. that the conventions and terminology defined in this
  88. Recommendation be used for Layer Service definitions of Open Systems
  89. Interconnection.
  90. .sp 1P
  91. .ce 1000
  92. CONTENTS
  93. .ce 0
  94. .sp 1P
  95. .sp 2P
  96. .LP
  97. 1
  98.     Scope and field of application
  99. .sp 1P
  100. .RT
  101. .LP
  102. 2
  103.     References
  104. .LP
  105. 3
  106.     Definitions
  107. .LP
  108. 4
  109.     Model for layer services
  110. .LP
  111. 5
  112.     Service primitives
  113. .LP
  114. 6
  115.     Conventions for time\(hysequence diagrams
  116. \v'3p'
  117. .LP
  118. \fIAppendix\ I\fR \ \(em\ Conventions for naming service primitives
  119. .LP
  120. \fIAppendix\ II\fR \ \(em\ Differences between Recommendation\ X.210 and ISO
  121. Technical Report\ 8509
  122. .sp 2P
  123. .LP
  124. \fB1\fR     \fBScope and field of application\fR 
  125. .sp 1P
  126. .RT
  127. .PP
  128. This Recommendation establishes definitions of terms and
  129. conventions for reference by other Recommendations which define the services
  130. provided by layers\ 1 to\ 6 of the Reference
  131. Model of Open Systems Interconnection for CCITT Applications
  132. (Recommendation\ X.200). These conventions are also applicable in specifying
  133. other telecommunications and data processing services and capabilities which
  134. utilize the layered model concepts and principles prescribed by the Reference 
  135. Model. In particular it is concerned with conventions relating to just 
  136. two 
  137. communicating systems at any one time, and connection\(hyoriented services.
  138. .bp
  139. .RT
  140. .sp 2P
  141. .LP
  142. \fB2\fR     \fBReferences\fR 
  143. .sp 1P
  144. .RT
  145. .PP
  146. Recommendation X.200\ \(em\ Reference Model of Open Systems
  147. Interconnection for CCITT Applications (see also ISO\ 7498).
  148. .RT
  149. .sp 2P
  150. .LP
  151. \fB3\fR     \fBDefinitions\fR 
  152. .sp 1P
  153. .RT
  154. .PP
  155. 3.1
  156. This Recommendation builds on the concepts developed in
  157. Recommendation\ X.200 and makes use of the following terms defined in that
  158. Recommendation:
  159. .sp 9p
  160. .RT
  161. .LP
  162.     a)
  163.     (N) layer;
  164. .LP
  165.     b)
  166.     (N) service;
  167. .LP
  168.     c)
  169.     (N) entity;
  170. .LP
  171.     d)
  172.     (N) service\(hyaccess\(hypoint;
  173. .LP
  174.     e)
  175.     (N) service\(hyaccess\(hypoint\(hyaddress.
  176. .PP
  177. \fINote\fR \ \(em\ The term \*Qservice\(hyaccess\(hypoint\*U is used when 
  178. describing the relationship between primitives associated with a single 
  179. connection. 
  180. Further study is required to include the concept of connection endpoints in
  181. this description.
  182. .PP
  183. 3.2
  184. For the purpose of this Recommendation, the following
  185. definitions also apply:
  186. .sp 9p
  187. .RT
  188. .sp 1P
  189. .LP
  190. 3.2.1
  191.     \fBservice\(hyuser\fR 
  192. .sp 9p
  193. .RT
  194. .PP
  195. An abstract representation of the totality of
  196. those entities in a single system that make use of a service through a 
  197. single access point. 
  198. .RT
  199. .sp 1P
  200. .LP
  201. 3.2.2
  202.     \fBservice\(hyprovider\fR 
  203. .sp 9p
  204. .RT
  205. .PP
  206. An abstract machine which models the
  207. behaviour of the totality of the entities providing the service, as viewed 
  208. by the user. 
  209. .RT
  210. .sp 1P
  211. .LP
  212. 3.2.3
  213.     \fBservice\(hyprimitive; primitive\fR 
  214. .sp 9p
  215. .RT
  216. .PP
  217. An abstract, implementation
  218. independent interaction between a service\(hyuser and the service\(hyprovider.
  219. .RT
  220. .sp 1P
  221. .LP
  222. 3.2.4
  223.     \fBrequest (primitive)\fR 
  224. .sp 9p
  225. .RT
  226. .PP
  227. A primitive issued by a service\(hyuser to invoke some
  228. procedure.
  229. .RT
  230. .sp 1P
  231. .LP
  232. 3.2.5
  233.     \fBindication (primitive)\fR 
  234. .sp 9p
  235. .RT
  236. .PP
  237. A primitive issued by a service\(hyprovider either:
  238. .RT
  239. .LP
  240.     i)
  241.     to invoke some procedure; or
  242. .LP
  243.     ii)
  244.     to indicate that a procedure has been invoked by the
  245. service\(hyuser at the peer service\(hyaccess\(hypoint.
  246. .sp 1P
  247. .LP
  248. 3.2.6
  249.     \fBresponse (primitive)\fR 
  250. .sp 9p
  251. .RT
  252. .PP
  253. A primitive issued by a service\(hyuser to
  254. complete, at a particular service\(hyaccess\(hypoint, some procedure previously
  255. invoked by an indication at that service\(hyaccess\(hypoint.
  256. .RT
  257. .sp 1P
  258. .LP
  259. 3.2.7
  260.     \fBconfirm (primitive)\fR 
  261. .sp 9p
  262. .RT
  263. .PP
  264. A primitive issued by a service\(hyprovider
  265. to complete, at a particular service\(hyaccess\(hypoint, some procedure 
  266. previously 
  267. invoked by a request at that service\(hyaccess\(hypoint.
  268. .PP
  269. \fINote\fR \ \(em\ Confirms and responses can be positive or negative as
  270. appropriate to the circumstances.
  271. .bp
  272. .RT
  273. .sp 1P
  274. .LP
  275. 3.2.8
  276.     \fB(N)\(hymandatory\(hyservice\fR 
  277. .sp 9p
  278. .RT
  279. .PP
  280. A service which must be provided in the (N)\(hyservice.
  281. .RT
  282. .sp 1P
  283. .LP
  284. 3.2.9
  285.     \fB(N)\(hyprovider\(hyoptional\(hyservice\fR 
  286. .sp 9p
  287. .RT
  288. .PP
  289. A service which may or may not be provided in the
  290. (N)\(hyservice.
  291. .RT
  292. .LP
  293. .sp 1P
  294. .LP
  295. 3.2.10
  296.     \fB(N)\(hyuser\(hyoptional\(hyservice\fR 
  297. .sp 9p
  298. .RT
  299. .PP
  300. A service which will only be provided if the (N)\(hyservice\(hyuser
  301. requests it, and it is available in the (N)\(hyservice.
  302. .RT
  303. .sp 1P
  304. .LP
  305. 3.2.11
  306.     \fBunconfirmed\(hyservice\fR 
  307. .sp 9p
  308. .RT
  309. .PP
  310. A service which does not result in an explicit confirmation.
  311. .RT
  312. .sp 1P
  313. .LP
  314. 3.2.12
  315.     \fBconfirmed\(hyservice\fR 
  316. .sp 9p
  317. .RT
  318. .PP
  319. A service which results in
  320. an explicit confirmation from the service\(hyprovider. There is not necessarily
  321. any relationship to a response from the peer service\(hyuser.
  322. .RT
  323. .sp 1P
  324. .LP
  325. 3.2.13
  326.     \fBprovider\(hyintitiated\(hyservice\fR 
  327. .sp 9p
  328. .RT
  329. .PP
  330. A service which is generated by the
  331. service\(hyprovider.
  332. .RT
  333. .sp 2P
  334. .LP
  335. \fB4\fR     \fBModel for layer services\fR 
  336. .sp 1P
  337. .RT
  338. .PP
  339. A layer service is defined in terms of an abstract model having the following 
  340. elements: 
  341. .RT
  342. .LP
  343.     a)
  344.     (N)\(hyservice\(hyusers;
  345. .LP
  346.     b)
  347.     (N)\(hyservice\(hyprovider.
  348. .PP
  349. For the lifetime of a particular connection each service\(hyuser
  350. gains access to the service\(hyprovider as indicated in Figure\ 1/X.210.
  351. .LP
  352. .rs
  353. .sp 13P
  354. .ad r
  355. \fBFigure 1/X.210, p.\fR 
  356. .sp 1P
  357. .RT
  358. .ad b
  359. .RT
  360. .PP
  361. Each service\(hyuser interacts with the service\(hyprovider by issuing 
  362. or receiving service\(hyprimitives. The layer service defines relations 
  363. between 
  364. interactions at one service\(hyaccess\(hypoint and consequential interactions 
  365. at 
  366. service\(hyaccess\(hypoints used by service\(hyusers in order to communicate.
  367. .bp
  368. .PP
  369. The relationship among the terms service, boundary, service primitive, 
  370. peer protocol, and peer entities are illustrated in Figure 2/X.210. 
  371. .RT
  372. .LP
  373. .rs
  374. .sp 24P
  375. .ad r
  376. \fBFigure 2/X.210, p.\fR 
  377. .sp 1P
  378. .RT
  379. .ad b
  380. .RT
  381. .sp 2P
  382. .LP
  383. \fB5\fR     \fBService primitives\fR 
  384. .sp 1P
  385. .RT
  386. .PP
  387. \fINote\fR \ \(em\ The detailed properties of service primitives are for
  388. further study.
  389. .RT
  390. .sp 1P
  391. .LP
  392. 5.1
  393.     \fIGeneral\fR 
  394. .sp 9p
  395. .RT
  396. .PP
  397. The use of primitives does not preclude any specific implementation of 
  398. a service in terms of interface primitives. The following comments apply 
  399. to this definition technique based on service primitives: 
  400. .RT
  401. .LP
  402.     a)
  403.     service primitives are conceptual, and need not be either
  404. directly related to protocol elements, or seen as macro calls of
  405. an access method to the layer service;
  406. .LP
  407.     b)
  408.      there are other equivalent sets of service primitives which can describe 
  409. the same layer service; 
  410. .LP
  411.     c)
  412.      only service primitives which correspond to some element of the layer 
  413. service involving two service\(hyusers need to be 
  414. considered. The primitives which are only related to local
  415. conventions
  416. .LP
  417. between the service\(hyuser and service\(hyprovider do not relate to
  418. this description technique. For example, strictly local
  419. functions could be provided in some implementations. As they do
  420. not involve both users, such functions are not visible outside
  421. the local system.
  422. .sp 1P
  423. .LP
  424. 5.2
  425.     \fICategories of service\fR 
  426. .sp 9p
  427. .RT
  428. .PP
  429. The following types of service are identified:
  430. .RT
  431. .LP
  432.     a)
  433.     mandatory\(hyservice (see \(sc 3.2.8);
  434. .LP
  435.     b)
  436.     provider\(hyoptional\(hyservice (see \(sc 3.2.9);
  437. .LP
  438.     c)
  439.     user\(hyoptional\(hyservice (see \(sc 3.2.10).
  440. .PP
  441. A user optional service may be either a mandatory service or a
  442. provider optional service.
  443. .bp
  444. .sp 1P
  445. .LP
  446. 5.3
  447.     \fITypes of service primitives\fR 
  448. .sp 9p
  449. .RT
  450. .PP
  451. Four types of service primitives are identified:
  452. .RT
  453. .LP
  454.     a)
  455.     request primitive (see \(sc 3.2.4);
  456. .LP
  457.     b)
  458.     indication primitive (see \(sc 3.2.5);
  459. .LP
  460.     c)
  461.     response primitive (see \(sc 3.2.6);
  462. .LP
  463.     d)
  464.     confirm primitive (see \(sc 3.2.7).
  465. .sp 1P
  466. .LP
  467. 5.4
  468.     \fIProperties of primitives\fR 
  469. .sp 9p
  470. .RT
  471. .PP
  472. An individual service primitive is a logically separate interaction which 
  473. cannot be interrupted by another interaction. A service primitive has a 
  474. direction which is either: 
  475. .RT
  476. .LP
  477.     a)
  478.     from a service\(hyuser to the service\(hyprovider;
  479. .LP
  480.     b)
  481.     from the service\(hyprovider to a service\(hyuser.
  482. .PP
  483. One or more parameters may be associated with a service primitive and each 
  484. of these parameters has a defined range of values. Parameter values 
  485. associated with a service primitive are passed in the direction of the 
  486. service primitive. 
  487. .sp 1P
  488. .LP
  489. 5.5
  490.     \fINames of primitives\fR 
  491. .sp 9p
  492. .RT
  493. .PP
  494. The name of each service primitive contains three
  495. elements:
  496. .RT
  497. .LP
  498.     a)
  499.     an initial (or initials) which specifies the layer (see
  500. \(sc\ I.1);
  501. .LP
  502.     b)
  503.     a name which specifies the service\(hyname (see \(sc\ I.2);
  504. .LP
  505.     c)
  506.     a name which specifies the type of primitive (see
  507. \(sc\ I.3).
  508. .sp 2P
  509. .LP
  510. \fB6\fR     \fBConventions for time\(hysequence diagrams\fR 
  511. .sp 1P
  512. .RT
  513. .PP
  514. Time\(hysequence diagrams are used to illustrate how sequences of
  515. interactions are related in time.
  516. .PP
  517. Time\(hysequence diagrams (see Figure 3/X.210) indicate:
  518. .RT
  519. .LP
  520.     a)
  521.     the sequence of events at each user/provider interface;
  522. .LP
  523.     b)
  524.     where appropriate, the sequence of events between peer
  525. users.
  526. .PP
  527. Each diagram is partitioned by two vertical lines into three
  528. fields. The central field represents the service\(hyprovider and the two side
  529. fields represent the two service\(hyusers. The lines represent the
  530. service\(hyaccess\(hypoints between the service\(hyusers and the service\(hyprovider. 
  531. .PP
  532. Sequences of events at each service\(hyaccess\(hypoint are positioned
  533. along lines representing the passage of time, increasing downwards. Arrows,
  534. placed in the areas representing the service\(hyuser, indicate the direction of
  535. propagation of primitives (i.e.,\ \fIto\fR or \fIfrom\fR the service\(hyuser) 
  536. and may 
  537. include implicit flow control between the service\(hyuser and service\(hyprovider. 
  538. .PP
  539. Necessary sequence relations between the two interaction points are
  540. emphasized by a solid line between the time lines (e.g.,\ in Figure\ 3a/X.210 
  541. the request primitive from one service\(hyuser to the service\(hyprovider 
  542. at time t\d1\uis necessarily followed by the indication primitive to the 
  543. peer service\(hyuser at time t\d2\u). In the absence of this solid line, 
  544. there is no specific 
  545. relationship
  546. between the delivery of confirmation and indication. The absence of
  547. relationship is indicated either by leaving the central field blank or, for
  548. clarity, by use of a tilde (\o"n~").
  549. .PP
  550. Figures 3b and 3c/X.210 present alternative methods of indicating
  551. negative acknowledgements generated by the responding service\(hyuser. In
  552. Figure\ 3b/X.210 the same name (e.g.,\ X) is used throughout the complete
  553. sequence, whereas in Figure\ 3c/X.210 the responding service\(hyuser employs a
  554. request with a different name (e.g.,\ Y).
  555. .bp
  556. .RT
  557. .LP
  558. .rs
  559. .sp 40P
  560. .ad r
  561. \fBFigure 3/X.210, p. 3\fR 
  562. .sp 1P
  563. .RT
  564. .ad b
  565. .RT
  566. .ce 1000
  567. APPENDIX\ I
  568. .ce 0
  569. .ce 1000
  570. (to Recommendation X.210)
  571. .sp 9p
  572. .RT
  573. .ce 0
  574. .ce 1000
  575. \fBConventions for naming service primitives\fR 
  576. .sp 1P
  577. .RT
  578. .ce 0
  579. .PP
  580. (This Appendix is not an integral part of the body of the
  581. Recommendation. It provides information for the authors of service
  582. Recommendations but is not necessary for users of service
  583. Recommendations.)
  584. .bp
  585. .sp 1P
  586. .RT
  587. .sp 2P
  588. .LP
  589. I.1
  590.     \fIInitials\fR 
  591. .sp 1P
  592. .RT
  593. .PP
  594. The following initials are used to specify Application services and the 
  595. layers of the OSI Model: 
  596. .RT
  597. .LP
  598.     a)
  599.     P
  600.     \(em\ Presentation Layer;
  601. .LP
  602.     b)
  603.     S
  604.     \(em\ Session Layer;
  605. .LP
  606.     c)
  607.     T
  608.     \(em\ Transport Layer;
  609. .LP
  610.     d)
  611.     N
  612.     \(em\ Network Layer (see note 1);
  613. .LP
  614.     e)
  615.     DL
  616.     \(em\ Data\(hyLink Layer;
  617. .LP
  618.     f
  619. )
  620.     Ph
  621.     \(em\ Physical Layer.
  622. .PP
  623. \fINote\ 1\fR \ \(em\ The use of `N' to signify the Network Layer is not 
  624. to be confused with the use of `(N)\(hy' to signify a particular but unspecified 
  625. layer of the Model.
  626. .PP
  627. \fINote\ 2\fR \ \(em\ Selection of initials for the various types of Application 
  628. services requires further study. 
  629. .RT
  630. .sp 2P
  631. .LP
  632. I.2
  633.     \fIService name\fR 
  634. .sp 1P
  635. .RT
  636. .PP
  637. A single word consisting of the infinitive form of a verb is
  638. recommended for the service name (e.g.,\ CONNECT, ABORT).
  639. .RT
  640. .sp 2P
  641. .LP
  642. I.3
  643.     \fIName of primitive type\fR 
  644. .sp 1P
  645. .RT
  646. .PP
  647. The name of the primitive type consists of one of the following
  648. (indicating the type of the primitive):
  649. .RT
  650. .LP
  651.     a)
  652.     request;
  653. .LP
  654.     b)
  655.     indication;
  656. .LP
  657.     c)
  658.     response (positive or negative);
  659. .LP
  660.     d)
  661.     confirm (positive or negative).
  662. .sp 2P
  663. .LP
  664. I.4
  665.     \fIRepresentation\fR 
  666. .sp 1P
  667. .RT
  668. .PP
  669. The initial(s) is represented in the form given in \(sc\ I.1. The
  670. service name is written in capital letters and the name of the
  671. primitive type is written in lower case letters.
  672. .PP
  673. The initial(s) and the service name are separated by a hyphen;
  674. the service name and primitive type are separated by a space.
  675. .RT
  676. .sp 2P
  677. .LP
  678. I.5
  679.     \fIExamples\fR 
  680. .sp 1P
  681. .RT
  682. .PP
  683. The following are examples of primitive names which use these
  684. conventions:
  685. .RT
  686. .LP
  687.     a)
  688.     P\(hyCONNECT request;
  689. .LP
  690.     b)
  691.     T\(hyDATA indication;
  692. .LP
  693.     c)
  694.     S\(hyDISCONNECT confirm.
  695. \v'6p'
  696. .LP
  697. .ce 1000
  698. APPENDIX\ II
  699. .ce 0
  700. .ce 1000
  701. (to Recommendation X.210)
  702. .sp 9p
  703. .RT
  704. .ce 0
  705. .ce 1000
  706. \fBDifferences between Recommendation X.210 and\fR 
  707. .sp 1P
  708. .RT
  709. .ce 0
  710. .ce 1000
  711. \fBISO Technical Report 8509\fR 
  712. .ce 0
  713. .PP
  714. II.1
  715. CCITT Recommendation X.210 and ISO Technical Report 8509 are technically 
  716. aligned to the extent that ISO layer service definitions using 
  717. these conventions are not affected. However, there are a number of detailed
  718. wording differences that remain to be reconciled.
  719. .bp
  720. .sp 1P
  721. .RT
  722. .sp 2P
  723. .LP
  724. \fBRecommendation\ X.211\fR 
  725. .RT
  726. .sp 2P
  727. .ce 1000
  728. \fBPHYSICAL\ SERVICE\ DEFINITION\ OF\ OPEN\ SYSTEMS\ INTERCONNECTION\fR 
  729. .EF '%    Fascicle\ VIII.4\ \(em\ Rec.\ X.211''
  730. .OF '''Fascicle\ VIII.4\ \(em\ Rec.\ X.211    %'
  731. .ce 0
  732. .sp 1P
  733. .ce 1000
  734. \fBFOR\ CCITT\ APPLICATIONS\fR 
  735. .FS
  736. Recommendation\ X.211 and ISO/IEC\ 10022 [Information Processing Systems\ 
  737. \(em\ Open Systems 
  738. Interconnection\ \(em\ Physical Layer Service Definition] were developed 
  739. in close 
  740. collaboration and are technically aligned.
  741. .FE
  742. .ce 0
  743. .sp 1P
  744. .ce 1000
  745. \fI(Melbourne, 1988)\fR 
  746. .sp 9p
  747. .RT
  748. .ce 0
  749. .sp 1P
  750. .sp 2P
  751. .LP
  752.     The\ CCITT
  753. .sp 1P
  754. .RT
  755. .sp 1P
  756. .LP
  757. \fIconsidering\fR 
  758. .sp 9p
  759. .RT
  760. .PP
  761. (a)
  762. that Recommendation X.200 defines the Reference Model of Open Systems Interconnection 
  763. (OSI) for CCITT Applications; 
  764. .PP
  765. (b)
  766. that Recommendation X.210 defines the Service
  767. conventions for describing the Services of the layers of the OSI Reference
  768. Model;
  769. .sp 1P
  770. .LP
  771. \fIUnanimously recommends\fR 
  772. .sp 9p
  773. .RT
  774. .PP
  775. that this Recommendation provides the specification for the
  776. functions of the Physical Layer Service for operation in the Open Systems
  777. Interconnection environment using various transmission modes, topologies, 
  778. and media. 
  779. .sp 1P
  780. .ce 1000
  781. CONTENTS
  782. .ce 0
  783. .sp 1P
  784. .LP
  785. 0
  786.     Introduction
  787. .sp 1P
  788. .RT
  789. .LP
  790. 1
  791.     Scope and Field of Application
  792. .LP
  793. 2
  794.     References
  795. .LP
  796. 3
  797.     Definitions
  798. .LP
  799. 4
  800.     Abbreviations
  801. .LP
  802. 5
  803.     Conventions
  804. .LP
  805. 6
  806.     Overview and General Characteristics
  807. .LP
  808. 7
  809.     Features of the Physical Service
  810. .LP
  811. 8
  812.     Classes of Physical Service
  813. .LP
  814. 9
  815.     Model of the Physical Service
  816. .LP
  817. 10
  818.     Quality of Physical Service
  819. .LP
  820. 11
  821.     Sequence of Primitives
  822. .LP
  823. 12
  824.     Connection Activation Phase
  825. .LP
  826. 13
  827.     Connection Deactivation Phase
  828. .LP
  829. 14
  830.     Data Transfer Phase
  831. .sp 2P
  832. .LP
  833. \fB0\fR     \fBIntroduction\fR 
  834. .sp 1P
  835. .RT
  836. .sp 1P
  837. .LP
  838. 0.1
  839.     \fIAbout this Recommendation\fR 
  840. .sp 9p
  841. .RT
  842. .PP
  843. This Recommendation is one of a set of Recommendations produced to facilitate 
  844. the interconnection of information processing systems. It is related to 
  845. other Recommendations in the set as defined by Recommendation\ X.200. 
  846. Reference Model of Open Systems Interconnection for CCITT Applications. The
  847. Reference Model of Open System Interconnection\ (OSI) subdivides the area of
  848. standardization for interconnection into a series of layers of specification, 
  849. each of manageable size. 
  850. .bp
  851. .PP
  852. This Recommendation defines the Service provided by the Physical Layer 
  853. to the Data Link Layer at the boundary between the Physical and Data Link 
  854. layers of the OSI\ Reference Model. It provides for the designers of Data 
  855. Link Protocols a definition of the Physical Service existing to support 
  856. the Data 
  857. Link Protocols and for the designers of Physical Protocols a definition 
  858. of the Services to be made available through the action of the Physical 
  859. Protocol 
  860. over the underlying physical media, which are external to the OSI Physical
  861. Layer. The relationship of the Physical Layer with the Data Link Layer is
  862. illustrated in Figure\ 1/X.211.
  863. .RT
  864. .LP
  865. .rs
  866. .sp 21P
  867. .ad r
  868. \fBFigure 1/X.211, p.\fR 
  869. .sp 1P
  870. .RT
  871. .ad b
  872. .RT
  873. .sp 2P
  874. .LP
  875. \fB1\fR     \fBScope and field of application\fR 
  876. .sp 1P
  877. .RT
  878. .PP
  879. This Recommendtion defines the OSI Physical Service in terms
  880. of:
  881. .RT
  882. .LP
  883.     a)
  884.     the privimitive actions and events, of the Service;
  885. .LP
  886.     b)
  887.     the parameters associated with each primitive and action and
  888. event, and the form which they take;
  889. .LP
  890.     c)
  891.     the interrelationship between, and the valid sequences of,
  892. these actions and events.
  893. .PP
  894. The principal objective of this Recommendation is to specify the characteristics 
  895. of a conceptual Physical Service and thus supplement the OSI 
  896. Reference Model in guiding the development of Physical protocols.
  897. .PP
  898. This Recommendation does not specify individual implementations or
  899. products nor does it constrain the implementation of entities and interfaces
  900. within an information processing system.
  901. .PP
  902. There is no conformance of equipment to this Physical Service
  903. Definition Recommendation. Instead, conformance is achieved through
  904. implementation of conforming OSI Physical protocols that fulfil the Physical
  905. Service defined in this Recommendation.
  906. .RT
  907. .sp 1P
  908. .LP
  909. \fB2\fR     \fBReferences\fR \v'3p'
  910. .sp 9p
  911. .RT
  912. .LP
  913.     1)
  914.     Recommendation\ X.200\ \(em
  915.     Reference Model of Open Systems
  916. Interconnection of CCITT Applications (see also ISO 7498).
  917. .LP
  918.     2)
  919.     Recommendation\ X.210\ \(em
  920.     Layer Service Definition
  921. Conventions of Open Systems Interconnection for CCITT Applications
  922. (see also ISO/TR\ 8509)
  923. .bp
  924. .sp 2P
  925. .LP
  926. \fB3\fR     \fBDefinitions\fR 
  927. .sp 1P
  928. .RT
  929. .sp 1P
  930. .LP
  931. 3.1
  932.     \fIReference Model Definitions\fR 
  933. .sp 9p
  934. .RT
  935. .PP
  936. This Recommendation is based on the concepts developed in the OSI Reference 
  937. Model, Recommendation\ X.200, and makes use of the following terms 
  938. defined in that Recommendation:
  939. .RT
  940. .LP
  941.     a)
  942.     Data circuit
  943. .LP
  944.     b)
  945.     Physical connection
  946. .LP
  947.     c)
  948.     Physical Layer
  949. .LP
  950.     d)
  951.     Physical media
  952. .LP
  953.     e)
  954.     Physical Service
  955. .LP
  956.     f
  957. )
  958.     Physical Service access point
  959. .LP
  960.     g)
  961.     Physical Service data unit
  962. .sp 1P
  963. .LP
  964. 3.2
  965.     \fIService Conventions Definition\fR 
  966. .sp 9p
  967. .RT
  968. .PP
  969. This Recommendation also makes use of the following terms defined in Recommendation\ 
  970. X.210, OSI Service Conventions, as they apply to the Physical Layer: 
  971. .RT
  972. .LP
  973.     a)
  974.     Physical Service user
  975. .LP
  976.     b)
  977.     Physical Service provider
  978. .LP
  979.     c)
  980.     primitive
  981. .LP
  982.     d)
  983.     request
  984. .LP
  985.     e)
  986.     indication
  987. .sp 2P
  988. .LP
  989. \fB4\fR     \fBAbbreviations\fR 
  990. .sp 1P
  991. .RT
  992. .LP
  993.     OSI
  994.     Open Systems Interconnection
  995. .LP
  996.     Ph
  997.     Physical
  998. .LP
  999.     PhC
  1000.     Physical connection
  1001. .LP
  1002.     PhL
  1003.     Physical Layer
  1004. .LP
  1005.     PhS
  1006.     Physical Service
  1007. .LP
  1008.     PhSAP
  1009.     Physical Service access point
  1010. .LP
  1011.     PhSDU
  1012.     Physical Service data unit
  1013. .LP
  1014.     PhPDU
  1015.     Physical Protocol data unit
  1016. .LP
  1017.     QOS
  1018.     Quality of Service
  1019. .sp 2P
  1020. .LP
  1021. \fB5\fR     \fBConventions\fR 
  1022. .sp 1P
  1023. .RT
  1024. .sp 1P
  1025. .LP
  1026. 5.1
  1027.     \fIGeneral Conventions\fR 
  1028. .sp 9p
  1029. .RT
  1030. .PP
  1031. This Recommendation uses the descriptive conventions given in
  1032. Recommendation\ X.210. OSI Service Conventions.
  1033. .PP
  1034. The layer service model, service primitive, and time\(hysequence diagrams 
  1035. taken from those conventions are entirely abstract descriptions; they do 
  1036. not 
  1037. represent a specification for implementation.
  1038. .RT
  1039. .sp 1P
  1040. .LP
  1041. 5.2
  1042.     \fIParameters\fR 
  1043. .sp 9p
  1044. .RT
  1045. .PP
  1046. Service primitives, used to represent PhS\(hyuser/provider
  1047. interactions (refer to Recommenation\ X.210) may convey parameters that 
  1048. indicate information available in the user/provider interaction. 
  1049. .PP
  1050. The parameters, which apply to each group of Physical Service
  1051. primitives, are set out in tables in Sections\ 11 to\ 14. The tables also
  1052. indicate the association of which parameters can be carried by each respective 
  1053. primitive. 
  1054. .PP
  1055. Some entries are further qualified by items in brackets. These may
  1056. be:
  1057. .RT
  1058. .LP
  1059.     a)
  1060.     an indication that the parameter is conditional in some
  1061. way:
  1062. .LP
  1063.     (C)\ indicates that the parameter is not present on the primitive
  1064. for every connection; the parameter definition describes the
  1065. conditions under which the parameter is present or absent;
  1066. .bp
  1067. .LP
  1068.     b)
  1069.     a parameter specific constraint:
  1070. .LP
  1071.     (=)\ indicates that the value supplied in an indication primitive
  1072. is always identical to that supplied in a previous request primitive
  1073. issued at the peer service access point;
  1074. .LP
  1075.     c)
  1076.     indication that some note applies to the entry:
  1077. .LP
  1078.     (note\ x)\ indicates that the referenced note contains additional
  1079. information pertaining to the parameter and its use.
  1080. .PP
  1081. In any particular interface, not all parameters used will be
  1082. explicitly stated. Some may be implicitly associated with the PhSAP at which
  1083. the primitive is issued.
  1084. .sp 1P
  1085. .LP
  1086. 5.3
  1087.     \fIPhC Endpoint Identification Convention\fR 
  1088. .sp 9p
  1089. .RT
  1090. .PP
  1091. If at a PhSAP there is more than one PhC, and distinction among
  1092. then is needed by the PhS user, PhC endpoint identification must be provided. 
  1093. All primitives issued at such a PhSAP would be required to use this mechanism 
  1094. to identify PhCs. Such an implicit identification is not described as a 
  1095. parameter of the service primitives in this Physical Service Definition.
  1096. .PP
  1097. When the PhC traverses relays, which are controlled through a separate 
  1098. PhC, an implicit identification mechanism must also provide for identification 
  1099. of these dependencies. 
  1100. .RT
  1101. .sp 2P
  1102. .LP
  1103. \fB6\fR     \fBOverview and general characteristics\fR 
  1104. .sp 1P
  1105. .RT
  1106. .PP
  1107. The Physical Service provides for the transparent transfer of data between 
  1108. PhS users. It makes invisible to the PhS users the way in which 
  1109. supporting communications resources are utilised to achieve this transfer.
  1110. Service classes are defined to categorize the distinctions that are visible 
  1111. to the PhS user. 
  1112. .PP
  1113. The PhS provides for a PhC between PhS users. Since connections cannot 
  1114. be established through the protocol at the Physical Layer but rather are 
  1115. configured when the service is created, the PhC, which is a logical concept,
  1116. nevertheless must relate directly to the real physical media paths provided 
  1117. to the Physical Layer. For this reason: 
  1118. .RT
  1119. .LP
  1120.     a)
  1121.     there is no distinction between connection\(hymode and
  1122. connectionless\(hymode at the Physical Layer. The service is
  1123. independent of whether the higher layers operate in
  1124. connection\(hymode or connectionless\(hymode;
  1125. .LP
  1126.     b)
  1127.     each PhC is identified within the Physical Layer;
  1128. .LP
  1129.     c)
  1130.     a PhC can only relate to a particular PhSAP (i.e., a PhC
  1131. implies a specific source PhSAP and a specific destination PhSAP
  1132. or group of PhSAPs if a multi\(hyendpoint connection).
  1133. .PP
  1134. The PhC may traverse Physical Layer relay, or intermediate systems when 
  1135. several physical media are used in tandem. Such relaying may be controlled 
  1136. through a management function exercised over a separate, but related PhC, 
  1137. or 
  1138. may be controlled from the Network Layer, as specified in Recommendation\ 
  1139. X.200, 
  1140. .PP
  1141. \(sc\ 7.5.4.1 for interconnection of data circuits. The Physical Layer does not
  1142. make any routing decisions. Intermediate systems may also be used for mapping 
  1143. different Physical Layer protocols associated with a PhC. 
  1144. .PP
  1145. Quality of Service provided by the Physical Service is predefined, in accordance 
  1146. with the class of service, though it may optionally be varied 
  1147. through management control of the configuration.
  1148. .PP
  1149. Actual data transmission takes place over the physical media. The
  1150. mechanical, electromagnetic, and other media dependent characteristics 
  1151. of the physical media are defined at the boundary (interface) between the 
  1152. Physical 
  1153. Layer and the physical media. Definitions of these characteristics are 
  1154. found in other CCITT Recommendations and International Standards. 
  1155. .RT
  1156. .sp 2P
  1157. .LP
  1158. \fB7\fR     \fBFeatures of the Physical Service\fR 
  1159. .sp 1P
  1160. .RT
  1161. .PP
  1162. 7.1
  1163. The Physical Service offers the following features to a PhS\fR 
  1164. user:
  1165. .sp 9p
  1166. .RT
  1167. .LP
  1168.     a)
  1169.     the means to activate a PhC with another PhS user for the
  1170. purpose of exchanging PhSDUs. More than one PhC may exist between the same 
  1171. pair of PhS users. The PhC Activate Service 
  1172. .LP
  1173. is optional and need not apply for duplex or simplex transmission
  1174. (i.e.\ continuous Data Transfer Phase);
  1175. .LP
  1176.     b)
  1177.      the means of transferring PhSDUs on a PhC. A PhSDU consists of one bit 
  1178. or a string of bits. PhSDUs are transferred in PhPDUs transparently 
  1179. over a PhC without change to the content (within the Quality of Service) or
  1180. constraint on their data values. PhSDUs are delivered in the same order in
  1181. which they are submitted;
  1182. .bp
  1183. .LP
  1184.     c)
  1185.      the means to identify, when necessary, individual PhCs at the PhSAPs. 
  1186. Note that the parameters to identify a particular PhC within the PhSAP 
  1187. are implicit (see \(sc\ 5.3); 
  1188. .LP
  1189.     d)
  1190.     the means for unconditional, and therefore possibly,
  1191. destructive deactivation of a PhC by either the PhS user or by the PhS
  1192. provider. The PhC Deactivate Service is optional and need not apply for 
  1193. duplex or simplex transmission (i.e.\ continuous Data Transfer Phase). 
  1194. .PP
  1195. 7.2
  1196. Other aspects of the Physical Service include:
  1197. .sp 9p
  1198. .RT
  1199. .LP
  1200.     a)
  1201.     the transfer of PhSDUs may be either duplex (two\(hyway
  1202. simultaneous), half\(hyduplex (two\(hyway alternate) or simplex (one way); 
  1203. either 
  1204. point\(hyto\(hypoint or multi\(hyendpoint; and either synchronous or asynchronous 
  1205. as 
  1206. appropriate (see \(sc\ 8);
  1207. .LP
  1208.     b)
  1209.     the data signalling rate on the physical media may not
  1210. correspond with the PhSDU throughput rate due to the inclusion of Physical
  1211. Layer protocol control information, multiplexing function, encoding mechanisms, 
  1212. or other transmission control functions; 
  1213. .LP
  1214.     c)
  1215.     PhSDU synchronization is provided by the Physical Service.
  1216. This includes bit synchronization. Other delimiting may be available, which 
  1217. is a veritable feature; 
  1218. .LP
  1219.     d)
  1220.      PhC endpoint identifiers are not globally known. In the case of multiplexing, 
  1221. they will be conveyed implicitly via the Physical Layer 
  1222. protocol;
  1223. .LP
  1224.     e)
  1225.      fault condition notification to the PhS user, beyond conveying a PhC 
  1226. deactivation indication, is for further study. 
  1227. .sp 2P
  1228. .LP
  1229. \fB8\fR     \fBClasses of Physical Services\fR 
  1230. .sp 1P
  1231. .RT
  1232. .PP
  1233. Distinctions of Physical Services are necessary to identify
  1234. features that relate to the requirements of the service as seen by the Data
  1235. Link Layer. These distinctions are:
  1236. .RT
  1237. .LP
  1238.     a)
  1239.     Type of transmission \(em synchronous and asynchronous.
  1240. .LP
  1241.     b)
  1242.     Mode of operation \(em duplex, half\(hyduplex, and simplex.
  1243. .LP
  1244.     \fINote\fR \ \(em\ While these modes describe the operation at the
  1245. Physical Layer Service boundary between the Physical Layer and
  1246. the Data Link Layer, they do not necessarily imply the specific
  1247. mode of operation of the Physical Layer Entity and the interface
  1248. between the Physical Layer and the underlying physical media.
  1249. This applies to operations associated with specific Physical
  1250. Service Provider implementations, such as collision detection
  1251. and multiplexing, which may map onto certain service primitives
  1252. (for example, Activation and Deactivation) but are otherwise
  1253. transparent to the Physical Service User.
  1254. .sp 2P
  1255. .LP
  1256. \fB9\fR     \fBModel of the Physical Service\fR 
  1257. .sp 1P
  1258. .RT
  1259. .sp 1P
  1260. .LP
  1261. 9.1
  1262.     \fIModel of the Layer Service\fR 
  1263. .sp 9p
  1264. .RT
  1265. .PP
  1266. This Recommendation uses the abstract model for a layer service
  1267. defined in \(sc\ 4 of Recommendation\ X.210, OSI Service Conventions. The model
  1268. defines the interactions between the PhS users and the PhS provider that 
  1269. take place at PhSAPs. Information is passed between the PhS user and the 
  1270. PhS 
  1271. provider by service primitives, which may convey parameters. The description 
  1272. of the model is applicable to point\(hyto\(hypoint PhCs (linking two PhSAPs). 
  1273. The 
  1274. extension of the model for multi\(hyendpoint PhCs is for further study.
  1275. .RT
  1276. .sp 1P
  1277. .LP
  1278. 9.2
  1279.     \fIModel of a physical connection\fR 
  1280. .sp 9p
  1281. .RT
  1282. .PP
  1283. The operation of a PhC is modeled in the abstract by a pair of bit streams 
  1284. linking the two PhSAPs. There is one bit stream for each direction of transmission 
  1285. (see Figure\ 2/X.211). Each bit stream conveys Physical Protocol 
  1286. Data Units (PhPDUs). Bits within each bit stream are delivered in the same
  1287. order in which they were submitted.
  1288. .bp
  1289. .RT
  1290. .sp 1P
  1291. .LP
  1292. 9.3
  1293.      \fIModel of a relayed point\(hyto\(hypoint PhC where the relay is controlled\fR 
  1294. \fIwithin the PhS Provider\fR 
  1295. .sp 9p
  1296. .RT
  1297. .PP
  1298. The operation of a PhC is modeled exactly as described in \(sc\ 9.2
  1299. except for the interposition of the relay within the data circuit to support
  1300. tandem physical media (see Figure\ 3/X.211).
  1301. .RT
  1302. .sp 1P
  1303. .LP
  1304. 9.4
  1305.      \fIModel of a relayed point\(hyto\(hypoint PhC where the relay is controlled\fR 
  1306. \fIfrom the Network Layer\fR 
  1307. .sp 9p
  1308. .RT
  1309. .PP
  1310. The operation of each of the relay\(hycontrolling PhCs can be
  1311. accomplished by the Network Layer protocol control information being conveyed 
  1312. either via the same PhC (in\(hyband signalling), or via a separate PhC 
  1313. (out\(hyof\(hyband signalling), see Figure\ 4/X.211. Physical Layer relay 
  1314. systems do not complete the end\(hyto\(hyend PhC until Network Layer control 
  1315. actions are 
  1316. completed among the Network Layer entities en route. Deactivation may be
  1317. accomplished through either Network layer protocol or management actions.
  1318. .RT
  1319. .LP
  1320. .rs
  1321. .sp 17P
  1322. .ad r
  1323. \fBFigure 2/X.211, p. 5\fR 
  1324. .sp 1P
  1325. .RT
  1326. .ad b
  1327. .RT
  1328. .LP
  1329. .rs
  1330. .sp 18P
  1331. .ad r
  1332. \fBFigure 3/X.211, p. 6\fR 
  1333. .sp 1P
  1334. .RT
  1335. .ad b
  1336. .RT
  1337. .LP
  1338. .bp
  1339. .LP
  1340. .rs
  1341. .sp 26P
  1342. .ad r
  1343. \fBFigure 4/X.211, p. 7\fR 
  1344. .sp 1P
  1345. .RT
  1346. .ad b
  1347. .RT
  1348. .sp 2P
  1349. .LP
  1350. \fB10\fR     \fBQuality of Physical Service\fR 
  1351. .sp 1P
  1352. .RT
  1353. .PP
  1354. The term \*QQuality of Service\*U (QOS) refers to certain
  1355. characteristics of a PhC as observed between the PhC endpoints. QOS describes 
  1356. aspects of a PhC that are attributable solely to the PhS provider: it can 
  1357. only be properly determined in the absence of PhS user behaviour (which 
  1358. is beyond 
  1359. the control of the PhS provider) that specifically constrains or impairs the
  1360. performance of the Physical Service.
  1361. .PP
  1362. The PhS users have knowledge of the relevant QOS of the PhC. This is true 
  1363. even in the case of a PhC scanning several physical circuits. 
  1364. .PP
  1365. The Quality of Service of a PhC is dependent on the physical media of interconnection. 
  1366. It may be characterized by: 
  1367. .RT
  1368. .LP
  1369.     a)
  1370.     service availability;
  1371. .LP
  1372.     b)
  1373.     error rate, where errors may arise from alteration, loss,
  1374. creation, and other causes;
  1375. .LP
  1376.     c)
  1377.     throughput;
  1378. .LP
  1379.     d)
  1380.     transit delay;
  1381. .LP
  1382.     e)
  1383.     protection (e.g. encryption).
  1384. .PP
  1385. QOS is described in terms of QOS parameters. These parameters are selected 
  1386. and determined by methods other than Physical Service primitives, 
  1387. although they may be determined in some cases through layer management
  1388. primitives.
  1389. .PP
  1390. There is no guarantee that the originally agreed upon QOS values will be 
  1391. maintained throughout the lifetime of the PhC. The PhS users should be 
  1392. aware that a change in QOS is not explicitly signalled in the Physical 
  1393. Service, 
  1394. .PP
  1395. although in some cases it may be signalled through layer management
  1396. primitives.
  1397. .bp
  1398. .RT
  1399. .sp 2P
  1400. .LP
  1401. \fB11\fR     \fBSequence of primitives\fR 
  1402. .sp 1P
  1403. .RT
  1404. .PP
  1405. This section defines the constraints on the sequences in which the primitives 
  1406. defined in \(sc\(sc\ 12\(hy14 may occur. The constraints determine the 
  1407. order in which primitives occur, but do not fully specify when they may 
  1408. occur. 
  1409. Table\ 1/X.211 is a summary of the PhS primitives and their parameters, and
  1410. defines the phases in which they occur (Activation, Data Transfer, and
  1411. Deactivation).
  1412. .RT
  1413. .LP
  1414. .sp 4
  1415. .ce
  1416. \fBH.T. [T1.211]\fR 
  1417. .ce
  1418. TABLE\ 1/X.211
  1419. .ce
  1420. \fBSummary of physical service primitives and
  1421. .ce
  1422. \fBparameters\fR 
  1423. .ps 9
  1424. .vs 11
  1425. .nr VS 11
  1426. .nr PS 9
  1427. .TS
  1428. center box;
  1429. cw(54p) | cw(54p) | cw(66p) | cw(54p) .
  1430. Phase      Service      Primitive      Parameters
  1431. _
  1432. .T&
  1433. lw(54p) | lw(54p) | lw(66p) | lw(54p) .
  1434. PhC activation (Note\ 1)    PhC activation    T{
  1435. Ph\(hyACTIVATE request
  1436. \|
  1437. Ph\(hyACTIVATE indication
  1438. T}    (Note\ 2)
  1439. _
  1440. .T&
  1441. lw(54p) | lw(54p) | lw(66p) | lw(54p) .
  1442. Data transfer    Data transfer    T{
  1443. Ph\(hyDATA request
  1444. \|
  1445. Ph\(hyDATA indication
  1446. T}    PhS\(hyUser data
  1447. _
  1448. .T&
  1449. lw(54p) | lw(54p) | lw(66p) | lw(54p) .
  1450. PhC deactivation (Note\ 1)    PhC deactivation    T{
  1451. Ph\(hyDEACTIVATE request
  1452. \|
  1453. Ph\(hyDEACTIVATE indication
  1454. T}    T{
  1455. (Note\ 3)
  1456. \fINote\ 1\fR
  1457. \ \(em\ The PhC activation and the PhC deactivation services are
  1458. optional and need not apply for duplex or simplex transmission.
  1459. .parag
  1460. \fINote\ 2\fR
  1461. \ \(em\ Parameters associated with the classes of service (see Section\ 8)
  1462. are for further study.
  1463. .parag
  1464. \fINote\ 3\fR
  1465. \ \(em\ Parameters associated with PhC deactivation are for further
  1466. study.
  1467. .parag
  1468. T}
  1469. _
  1470. .TE
  1471. .nr PS 9
  1472. .RT
  1473. .ad r
  1474. \fBTableau 1/X.211 [T1.211], p. 8\fR 
  1475. .sp 1P
  1476. .RT
  1477. .ad b
  1478. .RT
  1479. .sp 1P
  1480. .LP
  1481. .sp 5
  1482. 11.1
  1483.     \fIRelation of primitives at the two PhC endpoints\fR 
  1484. .sp 9p
  1485. .RT
  1486. .PP
  1487. A primitive issued at one PhC endpoint will, in general, have
  1488. consequences at the other PhC endpoint. The relations of primitives of each
  1489. .PP
  1490. type to primitives at the other PhC endpoint are defined in the appropriate
  1491. subsection in \(sc\(sc\ 12\(hy14; these relations are summarized in the 
  1492. diagrams in 
  1493. Figure\ 5/X.211. Additional sequences and relationships are for further
  1494. study.
  1495. .RT
  1496. .sp 1P
  1497. .LP
  1498. 11.2
  1499.     \fISequence of primitives at one PhC endpoint\fR 
  1500. .sp 9p
  1501. .RT
  1502. .PP
  1503. The recognized sequence of primitives at PhC endpoints is defined in the 
  1504. composite state transition diagram, Figure\ 6/X.211. Specific primitive 
  1505. sequences that apply to individual modes of operations and topologies are 
  1506. shown in Figures\ 6a/X.211 through 6i)/X.211. 
  1507. .bp
  1508. .RT
  1509. .LP
  1510. .rs
  1511. .sp 47P
  1512. .ad r
  1513. \fBFigure 5/X.211, p. 9\fR 
  1514. .sp 1P
  1515. .RT
  1516. .ad b
  1517. .RT
  1518. .LP
  1519. .bp
  1520. .LP
  1521. .rs
  1522. .sp 29P
  1523. .ad r
  1524. \fBFigure 6/X.211, p. 10\fR 
  1525. .sp 1P
  1526. .RT
  1527. .ad b
  1528. .RT
  1529. .LP
  1530. .rs
  1531. .sp 18P
  1532. .ad r
  1533. \fBFigure 6a/X.211, p. 11\fR 
  1534. .sp 1P
  1535. .RT
  1536. .ad b
  1537. .RT
  1538. .LP
  1539. .bp
  1540. .LP
  1541. .rs
  1542. .sp 21P
  1543. .ad r
  1544. \fBFigure 6b/X.211, p. 12\fR 
  1545. .sp 1P
  1546. .RT
  1547. .ad b
  1548. .RT
  1549. .LP
  1550. .rs
  1551. .sp 22P
  1552. .ad r
  1553. \fBFigure 6c/X.211, p. 13\fR 
  1554. .sp 1P
  1555. .RT
  1556. .ad b
  1557. .RT
  1558. .LP
  1559. .bp
  1560. .LP
  1561. .rs
  1562. .sp 23P
  1563. .ad r
  1564. \fBFigure 6d/X.211, p. 14\fR 
  1565. .sp 1P
  1566. .RT
  1567. .ad b
  1568. .RT
  1569. .LP
  1570. .rs
  1571. .sp 10P
  1572. .ad r
  1573. \fBFigure 6e/X.211, p. 15\fR 
  1574. .sp 1P
  1575. .RT
  1576. .ad b
  1577. .RT
  1578. .LP
  1579. .rs
  1580. .sp 9P
  1581. .ad r
  1582. \fBFigure 6f/X.211, p. 16\fR 
  1583. .sp 1P
  1584. .RT
  1585. .ad b
  1586. .RT
  1587. .LP
  1588. .bp
  1589. .LP
  1590. .rs
  1591. .sp 9P
  1592. .ad r
  1593. \fBFigure 6g/X.211, p. 17\fR 
  1594. .sp 1P
  1595. .RT
  1596. .ad b
  1597. .RT
  1598. .LP
  1599. .rs
  1600. .sp 17P
  1601. .ad r
  1602. \fBFigure 6h/X.211, p. 18\fR 
  1603. .sp 1P
  1604. .RT
  1605. .ad b
  1606. .RT
  1607. .LP
  1608. .rs
  1609. .sp 16P
  1610. .ad r
  1611. \fBFigure 6i/X.211, p. 19\fR 
  1612. .sp 1P
  1613. .RT
  1614. .ad b
  1615. .RT
  1616. .LP
  1617. .bp
  1618. .sp 2P
  1619. .LP
  1620. \fB12\fR     \fBPhC activation phase\fR 
  1621. .sp 1P
  1622. .RT
  1623. .sp 1P
  1624. .LP
  1625. 12.1
  1626.     \fIFunction\fR 
  1627. .sp 9p
  1628. .RT
  1629. .PP
  1630. The PhC activation service primitives are used for activating
  1631. directions of PhPDU transmission. They are required for half\(hyduplex and are
  1632. optional for duplex and simplex. The Ph\(hyACTIVATE request primitive requests
  1633. activation of the PhC. Each direction of transmission is activated
  1634. independently for half\(hyduplex operation, and both directions of transmission
  1635. are activated for duplex operation. For half\(hyduplex and simplex operation, 
  1636. the Ph\(hyACTIVATE request primitive activates the outgoing direction of 
  1637. transmission, and the Ph\(hyACTIVATE indication primitive indicates activation 
  1638. of the incoming direction of transmission. During half\(hyduplex operation, 
  1639. a Ph\(hyACTIVATE request cannot be issued by the PhS user after receipt 
  1640. of 
  1641. the Ph\(hyACTIVATE indication and before the receipt of a Ph\(hyDEACTIVATE 
  1642. indication primitive. 
  1643. .RT
  1644. .sp 1P
  1645. .LP
  1646. 12.2
  1647.     \fITypes of primitives and parameters\fR 
  1648. .sp 9p
  1649. .RT
  1650. .PP
  1651. The PhC activation service involves two primitives as shown in
  1652. Table\ 2/X.211. The parameters in the table are for further study.
  1653. .RT
  1654. .LP
  1655. .sp 1
  1656. .ce
  1657. \fBH.T. [T2.211]\fR 
  1658. .ce
  1659. TABLE\ 2/X.211
  1660. .ce
  1661. \fBPhysical service activate primitives and parameters\fR 
  1662. .ps 9
  1663. .vs 11
  1664. .nr VS 11
  1665. .nr PS 9
  1666. .TS
  1667. center box;
  1668. lw(78p) | cw(78p) | cw(72p) .
  1669. Primitive Parameter      Ph\(hyACTIVATE request      Ph\(hyACTIVATE indication
  1670. _
  1671. .T&
  1672. lw(78p) | cw(78p) | cw(72p) .
  1673. T{
  1674. (Note)
  1675. \fINote\fR
  1676. \ \(em\ Parameters associated with the classes of service (see Section\ 8)
  1677. are for further study.
  1678. .parag
  1679. T}        
  1680. _
  1681. .TE
  1682. .nr PS 9
  1683. .RT
  1684. .ad r
  1685. \fBTable 2/X.211 [T2.211], p.\fR 
  1686. .sp 1P
  1687. .RT
  1688. .ad b
  1689. .RT
  1690. .sp 1P
  1691. .LP
  1692. .sp 1
  1693. 12.3
  1694.     \fISequence of primitives\fR 
  1695. .sp 9p
  1696. .RT
  1697. .PP
  1698. The sequence of primitives in a successful activation of a
  1699. direction of transmission is defined by the time sequence diagram in
  1700. Figure\ 7/X.211.
  1701. .RT
  1702. .sp 2P
  1703. .LP
  1704. \fB13\fR     \fBPhC deactivation phase\fR 
  1705. .sp 1P
  1706. .RT
  1707. .sp 1P
  1708. .LP
  1709. 13.1
  1710.     \fIFunction\fR 
  1711. .sp 9p
  1712. .RT
  1713. .PP
  1714. The PhC deactivation service primitives are used for deactivating direction 
  1715. of PhPDU transmission. They are required for half\(hyduplex and are 
  1716. optional for duplex and simplex. The Ph\(hyDEACTIVATE request primitive 
  1717. requests deactivation of the PhC. Each direction of transmission is deactivated 
  1718. independently for half\(hyduplex operation, and both directions of transmission
  1719. are deactivated for duplex operation. For half\(hyduplex and simplex operation,
  1720. the Ph\(hyDEACTIVATE request primitive deactivates the outgoing direction of
  1721. transmission, and the Ph\(hyDEACTIVATE indication primitive indicates deactivation 
  1722. of the incoming direction of transmission. During half\(hyduplex operation, 
  1723. a 
  1724. Ph\(hyACTIVATE request primitive can be issued by a PhS user after receipt 
  1725. of the Ph\(hyDEACTIVATE indication primitive. 
  1726. .RT
  1727. .sp 1P
  1728. .LP
  1729. 13.2
  1730.     \fITypes of primitives and parameters\fR 
  1731. .sp 9p
  1732. .RT
  1733. .PP
  1734. The PhC deactivation service involves two primitives as shown in
  1735. Table\ 3/X.211.
  1736. .bp
  1737. .RT
  1738. .LP
  1739. .rs
  1740. .sp 30P
  1741. .ad r
  1742. \fBFigure 7/X.211, p. 21\fR 
  1743. .sp 1P
  1744. .RT
  1745. .ad b
  1746. .RT
  1747. .ce
  1748. \fBH.T. [T3.211]\fR 
  1749. .ce
  1750. TABLE\ 3/X.211
  1751. .ce
  1752. \fBPhysical service deactivate primitives and
  1753. .ce
  1754. parameters\fR 
  1755. .ps 9
  1756. .vs 11
  1757. .nr VS 11
  1758. .nr PS 9
  1759. .TS
  1760. center box;
  1761. lw(78p) | cw(78p) | cw(72p) .
  1762. Primitive Parameter      Ph\(hyDEACTIVATE request      Ph\(hyDEACTIVATE indication
  1763. _
  1764. .T&
  1765. lw(78p) | cw(78p) | cw(72p) .
  1766. T{
  1767. (Note)
  1768. \fINote\fR
  1769. \ \(em\ The need for deactivation parameters, e.g., Originator, are for
  1770. further
  1771. study. The Originator parameter indicates the source of the PhC deactivation. Its value indicates whether PhS user, PhS provider, or unknown caused the
  1772. action.
  1773. .parag
  1774. T}        
  1775. _
  1776. .TE
  1777. .nr PS 9
  1778. .RT
  1779. .ad r
  1780. \fBTableau 3/X.211 [T3.211], p. 22\fR 
  1781. .sp 1P
  1782. .RT
  1783. .ad b
  1784. .RT
  1785. .LP
  1786. .bp
  1787. .sp 1P
  1788. .LP
  1789. 13.3
  1790.     \fISequence of primitives\fR 
  1791. .sp 9p
  1792. .RT
  1793. .PP
  1794. The sequence of primitives for PhC deactivation are expressed in
  1795. the time sequence diagrams in Figure\ 8/X.211.
  1796. .RT
  1797. .LP
  1798. .rs
  1799. .sp 48P
  1800. .ad r
  1801. \fBFigure 8/X.211, p.\fR 
  1802. .sp 1P
  1803. .RT
  1804. .ad b
  1805. .RT
  1806. .LP
  1807. .bp
  1808. .sp 2P
  1809. .LP
  1810. \fB14\fR     \fBData transfer phase\fR 
  1811. .sp 1P
  1812. .RT
  1813. .sp 1P
  1814. .LP
  1815. 14.1
  1816.     \fIFunction\fR 
  1817. .sp 9p
  1818. .RT
  1819. .PP
  1820. The data transfer service primitives provide for an exchange of
  1821. user data called Physical Service Data Units (PhSDUs). The Physical Service
  1822. preserves the sequence of the PhSDUs.
  1823. .RT
  1824. .sp 1P
  1825. .LP
  1826. 14.2
  1827.     \fITypes of primitives and parameters\fR 
  1828. .sp 9p
  1829. .RT
  1830. .PP
  1831. Table 4/X.211 indicates the types of primitives and the parameters needed 
  1832. for data transfer. 
  1833. .RT
  1834. .ce
  1835. \fBH.T. [T4.211]\fR 
  1836. .ce
  1837. TABLE\ 4/X.211
  1838. .ce
  1839. \fBData transfer primitives and parameters\fR 
  1840. .ps 9
  1841. .vs 11
  1842. .nr VS 11
  1843. .nr PS 9
  1844. .TS
  1845. center box;
  1846. lw(78p) | cw(78p) | cw(72p) .
  1847. Primitive Parameter      Ph\(hyDATA request      Ph\(hyDATA indication
  1848. _
  1849. .T&
  1850. lw(78p) | cw(78p) | cw(72p) .
  1851. User data    X    X(=)
  1852. _
  1853. .TE
  1854. .nr PS 9
  1855. .RT
  1856. .ad r
  1857. \fBTable 4/X.211 [T4.211], p.\fR 
  1858. .sp 1P
  1859. .RT
  1860. .ad b
  1861. .RT
  1862. .PP
  1863. The User Data parameter conveys PhSDUs for transmission between
  1864. the PhS users. The size of the PhSDU is a PhS provider option. The PhS 
  1865. user has a prior knowledge of the PhSDU size value. 
  1866. .sp 1P
  1867. .LP
  1868. 14.3
  1869.     \fISequence of primitives\fR 
  1870. .sp 9p
  1871. .RT
  1872. .PP
  1873. The operation of the Physical Service in transferring PhSDUs can be modeled 
  1874. as a pair of bit streams within the PhS provider (see \(sc\ 9). 
  1875. .PP
  1876. The Physical Layer serves to pass a transparent bit stream (PhSDUs)
  1877. continuously. This requires that the Ph\(hyDATA primitives are present, as
  1878. necessary, throughout the Data Transfer Phase. Immediately upon receipt of a
  1879. .PP
  1880. Ph\(hyACTIVATE indication primitive, an incoming user data bit stream (PhSDUs) 
  1881. is available to the PhS user. Upon issuance of a Ph\(hyACTIVATE request 
  1882. primitive, an outgoing user data bit stream (PhSDUs) is assumed to be available 
  1883. to the PhS 
  1884. user.
  1885. .PP
  1886. The sequence of primitives in a successful data transfer is defined
  1887. in the time sequence diagram in Figure\ 9/X.211.
  1888. .RT
  1889. .LP
  1890. .rs
  1891. .sp 7P
  1892. .ad r
  1893. \fBFigure 9/X.211, p.\fR 
  1894. .sp 1P
  1895. .RT
  1896. .ad b
  1897. .RT
  1898. .PP
  1899. The sequence of primitives in Figure 9/X.211 may remain
  1900. uncompleted if an Ph\(hyDEACTIVATE primitive occurs.
  1901. .bp
  1902. .sp 2P
  1903. .LP
  1904. \fBRecommendation\ X.212\fR 
  1905. .RT
  1906. .sp 2P
  1907. .ce 1000
  1908. \fBDATA\ LINK\ SERVICE\ DEFINITION\ FOR\ OPEN\ SYSTEMS\fR 
  1909. .EF '%    Fascicle\ VIII.4\ \(em\ Rec.\ X.212''
  1910. .OF '''Fascicle\ VIII.4\ \(em\ Rec.\ X.212    %'
  1911. .ce 0
  1912. .sp 1P
  1913. .ce 1000
  1914. \fBINTERCONNECTION\ FOR\ CCITT\ APPLICATIONS\fR 
  1915. .FS
  1916. Recommendation X.212
  1917. and ISO 8886 [Information Procesing Systems \(em Data
  1918. Communications \(em Data Link Service Defintion] were developed in close
  1919. collaboration and are technically aligned, except for the differences noted in
  1920. Appendix\ I.
  1921. .FE
  1922. .ce 0
  1923. .sp 1P
  1924. .ce 1000
  1925. \fI(Melbourne, 1988)\fR 
  1926. .sp 9p
  1927. .RT
  1928. .ce 0
  1929. .sp 1P
  1930. .sp 2P
  1931. .LP
  1932.     The CCITT,
  1933. .sp 1P
  1934. .RT
  1935. .sp 1P
  1936. .LP
  1937. \fIconsidering\fR 
  1938. .sp 9p
  1939. .RT
  1940. .PP
  1941. (a)
  1942. that Recommendation X.200 defines the Reference Model of Open Systems Interconnection 
  1943. for CCITT applications; 
  1944. .PP
  1945. (b)
  1946. that Recommendation X.210 specifies the OSI Layer
  1947. Service Definition Conventions for describing the services of layers of 
  1948. the OSI Reference Model, 
  1949. .sp 1P
  1950. .LP
  1951. \fIunanimously recommends\fR 
  1952. .sp 9p
  1953. .RT
  1954. .PP
  1955. (1)
  1956. that the scope and field of application of the Open
  1957. Systems Interconnection Data Link Service Definition are given in \(sc\ 1;
  1958. .PP
  1959. (2)
  1960. that the general requirements of the Open Systems
  1961. Interconnection Data Link Service are given in Part\ 1;
  1962. .PP
  1963. (3)
  1964. that the connection\(hymode Data Link Service is defined  in Part\ 2;
  1965. .PP
  1966. (4)
  1967. that the connectionless\(hymode Data Link Service is
  1968. defined in Part\ 3.
  1969. .sp 1P
  1970. .ce 1000
  1971. CONTENTS\fR 
  1972. .ce 0
  1973. .sp 1P
  1974. .sp 2P
  1975. .LP
  1976. 0
  1977.     \fIIntroduction\fR 
  1978. .sp 1P
  1979. .RT
  1980. .sp 1P
  1981. .LP
  1982. 1
  1983.     \fIScope and field of application\fR 
  1984. .sp 9p
  1985. .RT
  1986. .sp 1P
  1987. .LP
  1988. 2
  1989.     \fIReferences\fR 
  1990. .sp 9p
  1991. .RT
  1992. .sp 2P
  1993. .LP
  1994. \fIPart One\fR \ \(em\ General
  1995. .sp 1P
  1996. .RT
  1997. .sp 1P
  1998. .LP
  1999. 3
  2000.     \fIDefinitions\fR 
  2001. .sp 9p
  2002. .RT
  2003. .LP
  2004.     3.1
  2005.     OSI Reference Model Definitions
  2006. .LP
  2007.     3.2
  2008.     Service Conventions Definitions
  2009. .LP
  2010.     3.3
  2011.     Data Link Service Definitions
  2012. .sp 1P
  2013. .LP
  2014. 4
  2015.     \fIAbbreviations\fR 
  2016. .sp 9p
  2017. .RT
  2018. .sp 1P
  2019. .LP
  2020. 5
  2021.     \fIConventions\fR 
  2022. .sp 9p
  2023. .RT
  2024. .LP
  2025.     5.1
  2026.     General Conventions
  2027. .LP
  2028.     5.2
  2029.     Parameters
  2030. .sp 1P
  2031. .LP
  2032. 6
  2033.     \fIOverview of the Data Link Service\fR 
  2034. .sp 9p
  2035. .RT
  2036. .sp 1P
  2037. .LP
  2038. 7
  2039.     \fIClasses, types and provided options of Data Link Service\fR .bp
  2040. .sp 9p
  2041. .RT
  2042. .sp 2P
  2043. .LP
  2044. \fIPart Two\fR \ \(em\ Definition of connection\(hymode service
  2045. .sp 1P
  2046. .RT
  2047. .sp 1P
  2048. .LP
  2049. 8
  2050.     \fIFeatures of the connection\(hymode Data Link Service\fR 
  2051. .sp 9p
  2052. .RT
  2053. .sp 1P
  2054. .LP
  2055. 9
  2056.     \fIModel of the connection\(hymode Data Link Service\fR 
  2057. .sp 9p
  2058. .RT
  2059. .LP
  2060.     9.1
  2061.     DLC Endpoint Connection Identification
  2062. .LP
  2063.     9.2
  2064.     Model of a Data link connection
  2065. .sp 1P
  2066. .LP
  2067. 10
  2068.     \fIQuality of connection\(hymode Data Link Service\fR 
  2069. .sp 9p
  2070. .RT
  2071. .LP
  2072.     10.1
  2073.     Determination of QOS for Connection\(hymode service
  2074. .LP
  2075.     10.2
  2076.     Definition of QOS Parameters
  2077. .sp 1P
  2078. .LP
  2079. 11
  2080.     \fISequence of primitives\fR 
  2081. .sp 9p
  2082. .RT
  2083. .LP
  2084.     11.1
  2085.     Concepts used to Model the Connection\(hymode Data Link Service
  2086. .LP
  2087.     11.2
  2088.     Constraints on Sequence of Primitives
  2089. .sp 1P
  2090. .LP
  2091. 12
  2092.     \fIConnection establishment phase\fR 
  2093. .sp 9p
  2094. .RT
  2095. .LP
  2096.     12.1
  2097.     Function
  2098. .LP
  2099.     12.2
  2100.     Types of Primitives and Parameters
  2101. .LP
  2102.     12.3
  2103.     Sequence of Primitives
  2104. .sp 1P
  2105. .LP
  2106. 13
  2107.     \fIConnection release phase\fR 
  2108. .sp 9p
  2109. .RT
  2110. .LP
  2111.     13.1
  2112.     Function
  2113. .LP
  2114.     13.2
  2115.     Types of Primitive and Parameters
  2116. .LP
  2117.     13.3
  2118.     Sequence of Primitives when Releasing an established DLC
  2119. .LP
  2120.     13.4
  2121.     Sequence of Primitives in a DLS User rejection of DLC
  2122. establishment attempt
  2123. .LP
  2124.     13.5
  2125.     Sequence of Primitives in a DLS Provider rejection of a DLC
  2126. establishment attempt
  2127. .LP
  2128.     13.6
  2129.     Sequence of Primitives in a DLS User abort of a DLC
  2130. connection attempt
  2131. .sp 1P
  2132. .LP
  2133. 14
  2134.     \fIData transfer phase\fR 
  2135. .sp 9p
  2136. .RT
  2137. .LP
  2138.     14.1
  2139.     Data transfer
  2140. .LP
  2141.     14.2
  2142.     Reset Service
  2143. .sp 2P
  2144. .LP
  2145. \fIPart Three\fR \ \(em\ Definition of connectionless\(hymode primitives
  2146. .sp 1P
  2147. .RT
  2148. .sp 1P
  2149. .LP
  2150. 15
  2151.     \fIFeatures of the connectionless\(hymode Data Link Service\fR 
  2152. .sp 9p
  2153. .RT
  2154. .sp 1P
  2155. .LP
  2156. 16
  2157.     \fIModel of the connectionless\(hymode Data Link Service\fR 
  2158. .sp 9p
  2159. .RT
  2160. .LP
  2161.     16.1
  2162.     Model of a Data\(hylink\(hyconnectionless\(hymode transmission
  2163. .sp 1P
  2164. .LP
  2165. 17
  2166.     \fIQuality of connectionless\(hymode service\fR 
  2167. .sp 9p
  2168. .RT
  2169. .LP
  2170.     17.1
  2171.     Determination of QOS for connectionless\(hymode service
  2172. .LP
  2173.     17.2
  2174.     Definition of connectionless\(hymode QOS Parameters
  2175. .sp 1P
  2176. .LP
  2177. 18
  2178.     \fIPermitted sequence of connectionless\(hymode primitives\fR .bp
  2179. .sp 9p
  2180. .RT
  2181. .sp 1P
  2182. .LP
  2183. 19
  2184.     \fIData transfer\fR 
  2185. .sp 9p
  2186. .RT
  2187. .LP
  2188.     19.1
  2189.     Functions
  2190. .LP
  2191.     19.2
  2192.     Types of primitives and parameters
  2193. .LP
  2194.     19.3
  2195.     Sequence of primitives
  2196. .sp 2P
  2197. .LP
  2198. \fIAppendix I\fR \ \(em
  2199.     Differences between CCITT and ISO texts
  2200. .sp 1P
  2201. .RT
  2202. .sp 1P
  2203. .LP
  2204. \fIAppendix II\fR \ \(em
  2205.     The relationship between the two types of Data Link
  2206. Service
  2207. .sp 9p
  2208. .RT
  2209. .sp 1P
  2210. .LP
  2211. \fIAppendix III\fR \ \(em
  2212.      Use of the X.25 LAPB compatible DTE data link procedures to provide the 
  2213. connection\(hymode data link service for open systems 
  2214. interconnection for CCITT applications.
  2215. .sp 9p
  2216. .RT
  2217. .sp 2P
  2218. .LP
  2219. \fB0\fR     \fBIntroduction\fR 
  2220. .sp 1P
  2221. .RT
  2222. .sp 1P
  2223. .LP
  2224. 0.1
  2225.     \fIAbout this Recommendation\fR 
  2226. .sp 9p
  2227. .RT
  2228. .PP
  2229. This Recommendation is one of a set of Recommendations produced to facilitate 
  2230. the interconnection of information processing systems. It is related to 
  2231. other Recommendations in the set as defined by Recommendation\ X.200, 
  2232. Reference Model of Open Systems Interconnection for CCITT Applications. The
  2233. reference model described by Recommendation\ X.200 subdivides the area of
  2234. standardization for Open Systems Interconnection (OSI) into a series of 
  2235. layers of specification, each of a manageable size. 
  2236. .PP
  2237. This Recommendation defines the services provided by the Data Link
  2238. Layer to the Network Layer at the boundary between the Data Link and Network
  2239. Layers of the OSI Reference Model. It provides for the designers of network
  2240. protocols a definition of the Data Link Service existing to support the 
  2241. network protocol and for the designers of Data Link Protocols a definition 
  2242. of the 
  2243. services to be made available through the action of the Data Link Protocol 
  2244. over ther underlying service. The relationship is illustrated in 
  2245. Figure\ 1/X.212.
  2246. .RT
  2247. .LP
  2248. .rs
  2249. .sp 11P
  2250. .ad r
  2251. \fBFigure 1/X.212, p.\fR 
  2252. .sp 1P
  2253. .RT
  2254. .ad b
  2255. .RT
  2256. .PP
  2257. Throughout the set of OSI Recommendations, the term \*Qservice\*U
  2258. refers to the abstract capability provided by one layer of the OSI Reference
  2259. Model to the layer immediately above. Thus, the Data Link Service defined in
  2260. this document is a conceptual architectural service, independent of
  2261. administrative divisions.
  2262. .sp 2P
  2263. .LP
  2264. \fB1\fR     \fBScope and field of application\fR 
  2265. .sp 1P
  2266. .RT
  2267. .PP
  2268. This Recommendation defines the OSI Data Link Service in terms
  2269. of:
  2270. .RT
  2271. .LP
  2272.     a)
  2273.     the primitive actions and events of the service;
  2274. .LP
  2275.     b)
  2276.     the parameters associated with each primitive action and
  2277. event, and the form that they take; and
  2278. .LP
  2279.     c)
  2280.     the interrelationship between, and the valid sequences of
  2281. these actions and events.
  2282. .bp
  2283. .PP
  2284. The principal objective of this Recommendation is to specify the characteristics 
  2285. of a conceptual Data Link Service and thus, supplement the OSI Reference 
  2286. Model in guiding the development of Data Link Protocols. 
  2287. .PP
  2288. This Recommendation does not specify individual implementation or
  2289. products, nor does it constrain the implementation of Data Link entities and
  2290. interfaces within an information processing system.
  2291. .PP
  2292. There is no conformance of equipment to this Data Link Service
  2293. Definition Recommendation. Instead, conformance is achieved through
  2294. implementation of conforming Data Link Protocols that fulfil the Data Link
  2295. Service defined in this Recommendation.
  2296. .RT
  2297. .sp 2P
  2298. .LP
  2299. \fB2\fR     \fBReferences\fR 
  2300. .sp 1P
  2301. .RT
  2302. .LP
  2303. Recommendation\ X.200\ \(em
  2304.     Reference Model of Open Systems
  2305. Interconnection for CCITT Applications (see also ISO\ 7498).
  2306. .LP
  2307. Recommendation\ X.210\ \(em
  2308.     OSI Layer Service Definition Conventions (see
  2309. also ISO\ TR8509).
  2310. .LP
  2311. PART ONE\ \(em\ GENERAL
  2312. .sp 1P
  2313. .RT
  2314. .sp 2P
  2315. .LP
  2316. \fB3\fR     \fBDefinitions\fR 
  2317. .sp 1P
  2318. .RT
  2319. .sp 1P
  2320. .LP
  2321. 3.1
  2322.     \fIOSI Reference Model Definitions\fR 
  2323. .sp 9p
  2324. .RT
  2325. .PP
  2326. This Recommendation is based on the concepts developed and makes
  2327. use of the following terms defined in Recommendation\ X.200:
  2328. .RT
  2329. .LP
  2330.     a)
  2331.     Data link entity
  2332. .LP
  2333.     b)
  2334.     Data Link Layer
  2335. .LP
  2336.     c)
  2337.     Data\(hylink\(hyService
  2338. .LP
  2339.     d)
  2340.     Data\(hylink\(hyservice\(hyaccess\(hypoint
  2341. .LP
  2342.     e)
  2343.     Data\(hylink\(hyservice\(hyaccess\(hypoint\(hyaddress
  2344. .LP
  2345.     f
  2346. )
  2347.     Data\(hylink\(hyservice\(hydata\(hyunit
  2348. .LP
  2349.     g)
  2350.     Reset.
  2351. .sp 1P
  2352. .LP
  2353. 3.2
  2354.     \fIService Conventions Definitions\fR 
  2355. .sp 9p
  2356. .RT
  2357. .PP
  2358. This Recommendation makes use of the following terms defined in
  2359. Recommendation\ X.210, as they apply to the Data Link Layer:
  2360. .RT
  2361. .LP
  2362.     a)
  2363.     Data Link Service User
  2364. .LP
  2365.     b)
  2366.     Data Link Service Provider
  2367. .LP
  2368.     c)
  2369.     Primitive
  2370. .LP
  2371.     d)
  2372.     Request
  2373. .LP
  2374.     e)
  2375.     Indication
  2376. .LP
  2377.     f
  2378. )
  2379.     Response
  2380. .LP
  2381.     g)
  2382.     Confirm
  2383. .sp 1P
  2384. .LP
  2385. 3.3
  2386.     \fIData Link Service Definitions\fR 
  2387. .sp 9p
  2388. .RT
  2389. .PP
  2390. This Recommendation makes use of the following terms:
  2391. .RT
  2392. .LP
  2393.     a)
  2394.     \fBdata\(hylink\(hyconnection\fR 
  2395. .LP
  2396.     An association established by a Data Link Layer between two
  2397. or more Data Link Service users for the transfer of data, which
  2398. provides explicit identification of a set of Data Link data
  2399. transmissions and agreement concerning the Data Link data
  2400. transmission services to be provided for the set.
  2401. .LP
  2402.     (\fINote\fR \ \(em\ This definition clarifies the definition given
  2403. in\ X.200.)
  2404. .bp
  2405. .LP
  2406.     b)
  2407.     \fBdata\(hylink\(hyconnection\(hymode data transmission\fR 
  2408. .LP
  2409.     The transmission of a Data\(hylink\(hyservice\(hydata\(hyunit within
  2410. the context of a Data\(hylink\(hyconnection that has been previously
  2411. established.
  2412. .LP
  2413.     c)
  2414.     \fBdata\(hylink\(hyconnectionless\(hymode data transmission\fR 
  2415. .LP
  2416.     The transmission of a Data\(hylink\(hyservice\(hydata\(hyunit not in the
  2417. context of a Data\(hylink\(hyconnection and not required to maintain
  2418. any logical relationship among multiple invocations.
  2419. .sp 2P
  2420. .LP
  2421. \fB4\fR     \fBAbbreviations\fR 
  2422. .sp 1P
  2423. .RT
  2424. .LP
  2425.     DL
  2426.     Data Link
  2427. .LP
  2428.     DLC
  2429.     Data\(hylink\(hyconnection
  2430. .LP
  2431.     DLL
  2432.     Data Link Layer
  2433. .LP
  2434.     DLS
  2435.     Data Link Service
  2436. .LP
  2437.     DLSAP
  2438.     Data\(hylink\(hyservice\(hyaccess\(hypoint
  2439. .LP
  2440.     DLSDU
  2441.     Data\(hylink\(hyservice\(hydata\(hyunit
  2442. .LP
  2443.     OSI
  2444.     Open Systems Interconnection
  2445. .LP
  2446.     QOS
  2447.     Quality of Service
  2448. .sp 2P
  2449. .LP
  2450. \fB5\fR     \fBConventions\fR 
  2451. .sp 1P
  2452. .RT
  2453. .sp 1P
  2454. .LP
  2455. 5.1
  2456.     \fIGeneral conventions\fR 
  2457. .sp 9p
  2458. .RT
  2459. .PP
  2460. This Recommendation uses the descriptive conventions given in
  2461. Recommendation\ X.210.
  2462. .PP
  2463. The service model, service primitives, and time\(hysequence diagrams used 
  2464. are entirely abstract descriptions; they do not represent a specification 
  2465. for implementation. 
  2466. .RT
  2467. .sp 1P
  2468. .LP
  2469. 5.2
  2470.     \fIParameters\fR 
  2471. .sp 9p
  2472. .RT
  2473. .PP
  2474. Service primitives, used to represent service user/service provider interactions 
  2475. (Recommendation\ X.210), convey parameters which indicate 
  2476. information available in the user/provider interaction.
  2477. .PP
  2478. The parameters which apply to each group of Data Link Service
  2479. primitives are set out in tables in sections\ 12 to\ 14 and\ 19. Each \*QX\*U 
  2480. in the tables indicates that the primitive labelling the column in which 
  2481. it falls may carry the parameter labelling the row in which it falls. 
  2482. .PP
  2483. Some entries are further qualified by items in brackets. These may
  2484. be:
  2485. .RT
  2486. .LP
  2487.     a)
  2488.     A parameter specific constraint:
  2489. .LP
  2490.     (*) indicates that the value supplied in an indication
  2491. or confirm primitive is always identical to that supplied in a previous 
  2492. request or response primitive issued at the peer service\(hyaccess\(hypoint 
  2493. .LP
  2494.     b)
  2495.     Indication that some note applies to the entry:
  2496. .LP
  2497.     (see note X) indicates that the referenced Note contains
  2498. additional information pertaining to the parameter and its use.
  2499. .PP
  2500. In any particular interface, not all parameters need be explicitly stated. 
  2501. Some may be implicitly associated with the DLSAP at which the primitive 
  2502. is issued. 
  2503. .sp 2P
  2504. .LP
  2505. \fB6\fR     \fBOverview of the Data Link Service\fR 
  2506. .sp 1P
  2507. .RT
  2508. .PP
  2509. The DLS provides for the transparent and reliable transfer of data between 
  2510. DLS users. It makes invisible to these DLS users the way in which 
  2511. supporting communications resources are utilized to achieve this transfer.
  2512. .PP
  2513. In particular, the DLS provides for the following:
  2514. .RT
  2515. .LP
  2516.     a)
  2517.      Independence of underlying Physical Layer \(em the DLS relieves DLS users 
  2518. from all concerns regarding which configuration is available 
  2519. (e.g.\ point\(hyto\(hypoint connection) or which physical facilities are used
  2520. (e.g.\ half\(hyduplex transmission).
  2521. .LP
  2522.     b)
  2523.      Transparency of transferred information \(em the DLS provides for the 
  2524. transparent transfer of DLS user\(hydata. It does not restrict the 
  2525. content, format or coding of the information, nor does it ever need to
  2526. interpret its structure or meaning.
  2527. .bp
  2528. .LP
  2529.     c)
  2530.     Reliable transfer of data \(em the DLS relieves the DLS user
  2531. from loss, insertion, corruption or, if requested, misordering of data which
  2532. may occur. In some cases of unrecoverable errors in the Data Link Layer,
  2533. duplication or loss of DLSDUs may occur.
  2534. .LP
  2535.      \fINote\fR \ \(em\ Detection of duplicate or lost DLSDUs may be performed 
  2536. by DLS users. 
  2537. .LP
  2538.     d)
  2539.     Quality of Service selection \(em the DLS makes available to
  2540. DLS users a means to request and to agree upon a quality of service for the
  2541. transfer of data. QOS is specified by means of QOS parameters representing
  2542. characteristics such as throughput, transit delay, accuracy and reliability.
  2543. .LP
  2544.     e)
  2545.      Addressing: The DLS allows the DLS user to identify itself and to specify 
  2546. the DLSAP to which a DLS is to be established whenever more than two DLSAPs 
  2547. are supported by the DLS provider. Data Link addresses have only 
  2548. local significance within a specific Data Link configuration over a single
  2549. transmission medium (point\(hyto\(hypoint or multi\(hypoint physical connection) 
  2550. or a 
  2551. group of parallel transmission media (multi\(hylink or splitting function).
  2552. Therefore it is not appopriate to define a global addressing structure.
  2553. .LP
  2554.     \fINote\fR \ \(em\ The DLS is required to differentiate between the
  2555. individual systems that are physically or logically connected to a multipoint 
  2556. data link and to differentiate between connections when the data link layer 
  2557. includes a multiplexing function. For commonality with other Service
  2558. definitions, this mechanism is referred to as addressing and the objects 
  2559. used to differentiate between systems are referred to as addresses. 
  2560. .sp 2P
  2561. .LP
  2562. \fB7\fR     \fBClasses and types of Data Link Service\fR 
  2563. .sp 1P
  2564. .RT
  2565. .PP
  2566. There are no distinct classes of Data Link Service defined.
  2567. .PP
  2568. There are two types of Data Link Service:
  2569. .RT
  2570. .LP
  2571.     a)
  2572.     a connection\(hymode service (defined in Part 2); and
  2573. .LP
  2574.     b)
  2575.     a connectionless\(hymode service (defined in Part 3).
  2576. .PP
  2577. When making reference to this Recommendation, a user or provider of Data 
  2578. Link Service shall state which types of service it expects to use or 
  2579. provide.
  2580. .LP
  2581. PART TWO\ \(em\ DEFINITION OF THE CONNECTION\(hyMODE SERVICE
  2582. .sp 1P
  2583. .RT
  2584. .sp 2P
  2585. .LP
  2586. \fB8\fR     \fBFeatures of the connection\(hymode Data Link Service\fR 
  2587. .sp 1P
  2588. .RT
  2589. .PP
  2590. The DLS provides the following features to the DLS user:
  2591. .RT
  2592. .LP
  2593.     a)
  2594.      the means to establish a DLC with another DLS user for the purpose of 
  2595. exchanging DLSDUs; 
  2596. .LP
  2597.     b)
  2598.      the establishment of an agreement between the initiating DLS user and 
  2599. the DLS provider for a certain QOS associated with each DLC; 
  2600. .LP
  2601.     c)
  2602.      the means of transferring DLSDUs of restricted length on a DLC. The transfer 
  2603. of DLSDUs is transparent, in that the boundaries of DLSDUs 
  2604. and the contents of DLSDUs are preserved unchanged by the DLS, and there 
  2605. are no constraints on the DLSDU content imposed by the DLS; 
  2606. .LP
  2607.      \fINote\fR \ \(em\ The length of a DLSDU may be limited because of internal 
  2608. mechanisms employed by the data\(hylink\(hyprotocol (see Recommendation\ 
  2609. X.200 
  2610. \(sc\ 7.6.3.2).
  2611. .LP
  2612.     d)
  2613.      the means by which the receiving DLS user may flow control the rate at 
  2614. which the sending DLS user may send DLSDUs; 
  2615. .LP
  2616.     e)
  2617.      the means by which a DLC can be returned to a defined state and the activities 
  2618. of the two DLS users synchronized by use of a Reset service element; 
  2619. .LP
  2620.     f
  2621. )
  2622.      the unconditional, and therefore possibly destructive, release of a DLC 
  2623. by either of the DLS users or by the DLS provider. 
  2624. .bp
  2625. .sp 2P
  2626. .LP
  2627. \fB9\fR     \fBModel of the connection\(hymode Data Link Service\fR 
  2628. .sp 1P
  2629. .RT
  2630. .PP
  2631. This Recommendation uses the abstract model for a layer service
  2632. defined in section\ 4 of Recommendation\ X.210. The model defines the
  2633. interactions between the DLS users and the DLS provider which take place 
  2634. at the two DLSAPs. Information is passed between the DLS user and the DLS 
  2635. provider by service primitives, which may convey parameters. 
  2636. .RT
  2637. .sp 1P
  2638. .LP
  2639. 9.1
  2640.     \fIDLC Endpoint Connection Identification\fR 
  2641. .sp 9p
  2642. .RT
  2643. .PP
  2644. If a DLS user needs to distinguish among several DLCs at the same DLSAP, 
  2645. then a local connection endpoint identification mechanism must be 
  2646. provided. All primitives issued at such a DLSAP within the context of a DLC
  2647. would be required to use this mechanism to identify this DLC. Such an implicit 
  2648. identification is not described in this Recommendation. 
  2649. .RT
  2650. .sp 1P
  2651. .LP
  2652. 9.2
  2653.     \fIModel of a Data\(hylink\(hyconnection\fR 
  2654. .sp 9p
  2655. .RT
  2656. .PP
  2657. Between the two endpoints of a DLC, there exists a flow control
  2658. function that relates the behaviour of the DLS user receiving data to the
  2659. ability of the other DLS user to send data. As a means of specifying this 
  2660. flow control feature and its relationship with other capabilities provided 
  2661. by the 
  2662. connection\(hymode DLS the queue model of a DLC, which is described in the
  2663. following sections, is used.
  2664. .PP
  2665. This queue model of a DLC is discussed only to aid in the
  2666. understanding of the end\(hyto\(hyend service features perceived by DLS 
  2667. users. It is not intended to serve as a substitute for a precise, formal 
  2668. description of the DLS, nor as a complete specification of all allowable 
  2669. sequences of DLS 
  2670. primitives. (Allowable primitive sequences are specified in section\ 11. See
  2671. also the note below.) In addition, this model does not attempt to describe 
  2672. all the functions or operations of DL entities that are used to provide 
  2673. the DLS. No attempt to specify or constrain DLS implementations is implied. 
  2674. .PP
  2675. \fINote\fR \ \(em\ The internal mechanisms which support the operation of the
  2676. DLS are not visible to the DLS user. In addition to the interactions between
  2677. service primitives described by this model (e.g.\ the issue of a DL\(hyReset
  2678. request at an DLSAP may prevent the receipt of a DL\(hyDATA indication,
  2679. corresponding to a previously issued DL\(hyDATA request, by the peer DLS user)
  2680. there may also be:
  2681. .RT
  2682. .LP
  2683.     a)
  2684.     constraints applied locally on the ability to invoke
  2685. primitives;
  2686. .LP
  2687.     b)
  2688.     service procedures defining particular sequencing
  2689. constraints on some primitives.
  2690. .sp 1P
  2691. .LP
  2692. 9.2.1
  2693.     \fIQueue model concepts\fR 
  2694. .sp 9p
  2695. .RT
  2696. .PP
  2697. The queue model represents the operation of a DLC in the abstract by a 
  2698. pair of queues linking the two DLSAPs. There is one queue for each 
  2699. direction of information flow (see Figure\ 2/X.212).
  2700. .RT
  2701. .LP
  2702. .rs
  2703. .sp 17P
  2704. .ad r
  2705. \fBFigure 2/X.212, p.\fR 
  2706. .sp 1P
  2707. .RT
  2708. .ad b
  2709. .RT
  2710. .LP
  2711. .bp
  2712. .PP
  2713. Each queue represents a flow control function in one direction of transfer. 
  2714. The ability of a DLS user to add objects to a queue will be 
  2715. determined by the behaviour of the other DLS queue. Objects are entered or
  2716. removed from the queue as a result of interactions at the two DLSAPs.
  2717. .PP
  2718. The pair of queues is considered to be available for each potential
  2719. DLC.
  2720. .PP
  2721. The following objects may be placed in a queue by a DLS user (see
  2722. sections\ 12\(hy14):
  2723. .RT
  2724. .LP
  2725.     a)
  2726.     a connect object, representing a DL\(hyCONNECT primitive and
  2727. its parameters;
  2728. .LP
  2729.     b)
  2730.     a data object, representing a DL\(hyDATA primitive and its
  2731. parameters;
  2732. .LP
  2733.     c)
  2734.     a reset object, representing a DL\(hyRESET primitive and its
  2735. parameters; and
  2736. .LP
  2737.     d)
  2738.      a disconnect object, representing a DL\(hyDISCONNECT primitive and its 
  2739. parameters. 
  2740. .PP
  2741. The following objects may be placed in a queue by the DLS\(hyprovider (see 
  2742. sections\ 12\(hy14): 
  2743. .LP
  2744.     1)
  2745.     a reset object, representing a DL\(hyRESET primitive and its
  2746. parameters;
  2747. .LP
  2748.     2)
  2749.     a synchronization mark object (see \(sc\ 9.2.4); and
  2750. .LP
  2751.     3)
  2752.      a disconnect object, representing a DL\(hyDISCONNECT primitive and its 
  2753. parameters. 
  2754. .PP
  2755. The queues are defined to have the following general
  2756. properties:
  2757. .LP
  2758.     i)
  2759.     a queue is empty before a connect object has been entered
  2760. and can be returned to this state, with loss of its contents, by the DLS
  2761. provider;
  2762. .LP
  2763.     ii)
  2764.      objects are entered into a queue by the sending DLS user, subject to 
  2765. control by the DLS provider. Objects may also be entered by the DLS provider; 
  2766. .LP
  2767.     iii)
  2768.      objects are removed from the queue, under the control of the receiving 
  2769. DLS user; 
  2770. .LP
  2771.     iv)
  2772.     objects are normally removed in the same order that they
  2773. were entered (however, see \(sc\ 9.2.3); and
  2774. .LP
  2775.     v)
  2776.     a queue has a limited capacity, but this capacity is not
  2777. necessarily either fixed or determinable.
  2778. .sp 1P
  2779. .LP
  2780. 9.2.2
  2781.     \fIDLC Establishment\fR 
  2782. .sp 9p
  2783. .RT
  2784. .PP
  2785. A pair of queues is associated with a DLC between two DLSAPs when the DLS 
  2786. provider receives a DL\(hyCONNECT request primitive at one of the DLSAPs, 
  2787. and a connect object is entered into one of the queues. From the standpoint 
  2788. of the DLS users of the DLC, the queues remain associated with the DLC 
  2789. until a 
  2790. disconnect object representing a DL\(hyDISCONNECT primitive is either entered 
  2791. or removed from the queue. 
  2792. .PP
  2793. DLS user A, who initiates a DLC establishment by entering a connect
  2794. object representing a DL\(hyCONNECT request primitive into the queue from DLS
  2795. user\ A to DLS user\ B, is not allowed to enter any other object, other than a
  2796. disconnect object, into the queue until after the connect object representing 
  2797. the DL\(hyCONNECT confirm primitive has been removed from the DLS user\ 
  2798. B to DLA 
  2799. user\ A queue. In the queue from DLS user\ B to DLS user\ A objects can 
  2800. be entered only after DLS user\ B has entered a connect object representing 
  2801. a DL\(hyCONNECT 
  2802. response primitive.
  2803. .PP
  2804. The properties exhibited by the queues while the DLC exists represent the 
  2805. agreements reached among the DLS users and the DLS provider during this 
  2806. connection establishment procedure concerning QOS.
  2807. .RT
  2808. .sp 1P
  2809. .LP
  2810. 9.2.3
  2811.     \fIData transfer\fR 
  2812. .sp 9p
  2813. .RT
  2814. .PP
  2815. Flow control on the DLC is respresented in this queue model by the management 
  2816. of the queue capacity, allowing objects to be added to the queues. The 
  2817. addition of an object may prevent addition of a further object. 
  2818. .bp
  2819. .PP
  2820. Once objects are in the queue, the DLS provider may manipulate pairs of 
  2821. adjacent objects, resulting in deletion. An object may be deleted if, and 
  2822. only if, the object which follows it is defined to be destructive with 
  2823. respect to the object. If necessary the last object in the queue will be 
  2824. deleted to 
  2825. allow a destructive object to be entered \(em they may therefore always 
  2826. be added to the queue. Disconnect objects are defined to be destructive 
  2827. with respect to all other objects. Reset objects are defined to be destructive 
  2828. with respect to all other objects except connect, disconnect objects. 
  2829. .PP
  2830. The relationships between objects which may be manipulated in the
  2831. above fashion are summarized in Table\ 1/X.212.
  2832. .PP
  2833. Whether the DLS provider performs actions resulting in deletion or not 
  2834. will depend upon the bahaviour of the DLC users and the agreed QOS for 
  2835. the DLC. In general, if a DLS user does not remove objects from a queue, 
  2836. the DLS 
  2837. provider shall, after some unspecified period of time, perform all the
  2838. permitted deletions.
  2839. .RT
  2840. .ce
  2841. \fBH.T. [T1.212]\fR 
  2842. .ce
  2843. TABLE\ 1/X.212
  2844. .ce
  2845. \fBRelationships between queue model objects\fR 
  2846. .ps 9
  2847. .vs 11
  2848. .nr VS 11
  2849. .nr PS 9
  2850. .TS
  2851. center box;
  2852. lw(60p) | cw(36p) | cw(24p) | cw(36p) | cw(36p) | cw(36p) .
  2853. T{
  2854. The following object
  2855. y is defined
  2856. \| \|
  2857. with
  2858. respect to the
  2859. preceding object x
  2860. T}    Connect    Data    Reset    T{
  2861. \| \|
  2862. \| \|
  2863. Synchronization mark
  2864. T}    Disconnect  
  2865. _
  2866. .T&
  2867. lw(60p) | cw(36p) | cw(24p) | cw(36p) | cw(36p) | cw(36p) .
  2868. Connect    N/A    \(em    \(em    N/A    DES
  2869. _
  2870. .T&
  2871. lw(60p) | cw(36p) | cw(24p) | cw(36p) | cw(36p) | cw(36p) .
  2872. Data    N/A    \(em    DES    N/A    DES
  2873. _
  2874. .T&
  2875. lw(60p) | cw(36p) | cw(24p) | cw(36p) | cw(36p) | cw(36p) .
  2876. Reset    N/A    \(em    DES    \(em    DES
  2877. _
  2878. .T&
  2879. lw(60p) | cw(36p) | cw(24p) | cw(36p) | cw(36p) | cw(36p) .
  2880. Synchronization mark    N/A    \(em    DES    N/A    DES
  2881. _
  2882. .T&
  2883. lw(60p) | cw(36p) | cw(24p) | cw(36p) | cw(36p) | cw(36p) .
  2884. Disconnect    N/A    N/A    N/A    N/A    T{
  2885. DES
  2886. N/A
  2887. :\ x will not precede y in a valid state of a queue
  2888. .parag
  2889. \(em
  2890. :\ Not to be destructive nor to be able to advance ahead
  2891. .parag
  2892. DES
  2893. :\ To be destructive to the preceding object
  2894. .parag
  2895. T}
  2896. _
  2897. .TE
  2898. .nr PS 9
  2899. .RT
  2900. .ad r
  2901. \fBTable [T1.212], p.\fR 
  2902. .sp 1P
  2903. .RT
  2904. .ad b
  2905. .RT
  2906. .sp 1P
  2907. .LP
  2908. 9.2.4
  2909.     \fIReset\fR 
  2910. .sp 9p
  2911. .RT
  2912. .PP
  2913. In order to accurately model the reset service a synchronization
  2914. mark object is required. The synchronization mark object exhibits the following 
  2915. properties: 
  2916. .RT
  2917. .LP
  2918.     a)
  2919.     it cannot be removed from a queue by a DLS\(hyuser;
  2920. .LP
  2921.     b)
  2922.      a queue appears empty to a DLS\(hyuser when a synchronization mark object 
  2923. is the next object in the queue; 
  2924. .LP
  2925.     c)
  2926.     a synchronization mark object can be destroyed by a
  2927. Disconnect object (see Table\ 1/X.212);
  2928. .LP
  2929.     d)
  2930.     when a Reset object is immediately preceded by a
  2931. synchronization mark object, both the Reset object and the synchronization 
  2932. mark object are deleted from the queue. 
  2933. .PP
  2934. The initiation of a reset procedure is represented in the two
  2935. queues as follows:
  2936. .LP
  2937.     i)
  2938.     initiation of a reset procedure by the DLS provider is
  2939. represented by the introduction into each queue of a reset object followed 
  2940. by a synchronization mark object; 
  2941. .LP
  2942.     ii)
  2943.      a reset procedure initiated by a DLS user is represented by the addition, 
  2944. by the DLS provider, of a reset object into the queue from the 
  2945. Reset initiator to the peer DLS user and the insertion of a reset object
  2946. followed by a synchronization mark object into the other queue.
  2947. .bp
  2948. .PP
  2949. Unless destroyed by a disconnect object, a synchronization mark
  2950. object remains in the queue until the next objet following it in the queue 
  2951. is a reset object. Both the synchronization mark object and the following 
  2952. reset 
  2953. object are then deleted by the DLS provider.
  2954. .PP
  2955. \fINote\fR \ \(em\ Associated with the initiation of a reset procedure are
  2956. restrictions on the issuance of certain other types of primitives. These
  2957. restrictions will result in restrictions on the entry of certain object 
  2958. types into the queue until the reset procedure is completed (see \(sc\ 
  2959. 14.2.3). 
  2960. .RT
  2961. .sp 1P
  2962. .LP
  2963. 9.2.5
  2964.     \fIDLC release\fR 
  2965. .sp 9p
  2966. .RT
  2967. .PP
  2968. The insertion into a queue of a disconnect object, which may occur at any 
  2969. time, represents the initiation of a DLC release procedure. The release 
  2970. procedure may be destructive with respect to other objects in the two queue 
  2971. and eventually results in the emptying of the queues and the disassociation 
  2972. of the queues with the DLC. 
  2973. .PP
  2974. The insertion of a disconnect object may also represent the rejection of 
  2975. a DLC establishment attempt or the failure to complete DLC establishment. 
  2976. In such cases, if a connect object representing a DL\(hyCONNECT request 
  2977. primitive is deleted by a disconnect object, then the disconnect object 
  2978. is also deleted. The disconnect object is not deleted when it deletes any 
  2979. other object, including 
  2980. the case where it deletes a connect object representing a DL\(hyCONNECT
  2981. response.
  2982. .RT
  2983. .sp 2P
  2984. .LP
  2985. \fB10\fR     \fBQuality of connection\(hymode Data Link Service\fR 
  2986. .sp 1P
  2987. .RT
  2988. .PP
  2989. The term \*QQuality of Service\*U (QOS) refers to certain
  2990. characteristics of a DLC as observed between the connection endpoints. QOS
  2991. describes aspects of a DLC that are attributable solely to the DLS provider.
  2992. .PP
  2993. Once a DLC is established, the DLS users at the two ends have the same 
  2994. knowledge and understanding of what the QOS over the DLC is. 
  2995. .RT
  2996. .sp 1P
  2997. .LP
  2998. 10.1
  2999.     \fIDetermination of QOS for Connection\(hymode Service\fR 
  3000. .sp 9p
  3001. .RT
  3002. .PP
  3003. QOS is determined in terms of QOS parameters. These parameters give DLS 
  3004. users a method of specifying their needs and give the DLS provider a basis 
  3005. for protocol selection. 
  3006. .PP
  3007. The DLS QOS parameters can be divided into the following two types,
  3008. based upon the way in which their values are determined:
  3009. .RT
  3010. .LP
  3011.     a)
  3012.     those QOS parameters which may be selected on a
  3013. per\(hyconnection basis during the establishment phase of a DLC;
  3014. .LP
  3015.     b)
  3016.     those QOS parameters which are not selected during DLC
  3017. establishment but whose values are known by other methods.
  3018. .PP
  3019. There are three QOS parameters, throughput, protection, and
  3020. priority (as defined in \(sc\(sc\ 10.2.1, 10.2.5 and 10.2.6 respectively), 
  3021. which are of the type that may be selected during DLC establishment. The 
  3022. selection 
  3023. procedures for these parameters are described in detail in \(sc\ 12.2.5. 
  3024. Once the DLC is established, throughout the lifetime of the DLC, the agreed 
  3025. QOS values are not reselected at any point, and there is no guarantee that 
  3026. the original 
  3027. values will be maintained. The DLS users should also be aware that changes 
  3028. in QOS on a DLC are not explicity signalled by the DLS provider. 
  3029. .PP
  3030. The remaining QOS characteristics that are identified as parameters, but 
  3031. for which there is no selection during DLC establishment, are defined in 
  3032. \(sc\(sc\ 10.2.2 through\ 10.2.4 respectively. The values of these parameters 
  3033. for a 
  3034. particular DLC are determined by other methods such as \fIa\ priori\fR 
  3035. knowledge and agreement. 
  3036. .PP
  3037. If selection is allowed, certain measures of QOS are requested by the sending 
  3038. DLS user when the DL\(hyCON primitive action is initiated. The requested 
  3039. measures (or parameter values and options) are based on \fIa\ priori\fR 
  3040. knowledge by the DLS user of the service(s) made available to it by the 
  3041. DLS provider. 
  3042. Knowledge of the characteristics and type of service provided (i.e.\ the
  3043. parameters, formats, and options that affect the transfer of data) is made
  3044. available to a DLS user through some layer management interaction prior to
  3045. (any) invocation of the DL connection\(hymode service. Thus, the DLS user has
  3046. explicit knowledge of the characteristics of the service it can expect to be
  3047. provided with each invocation of the service.
  3048. .bp
  3049. .PP
  3050. The DLS provider may also provide information on the current QOS
  3051. independently of access to the service by the DLS user. This seemingly 
  3052. dynamic aspect of QOS determination is not a negotiation but provided with 
  3053. knowledge of the characteristics of the service currently outside of any 
  3054. instance of the 
  3055. invocation of the service.
  3056. .RT
  3057. .sp 1P
  3058. .LP
  3059. 10.2
  3060.     \fIDefinition of connection\(hymode QOS parameters\fR 
  3061. .sp 9p
  3062. .RT
  3063. .PP
  3064. QOS parameters can be classified as:
  3065. .RT
  3066. .LP
  3067.     a)
  3068.     Parameters that express DLS performance, as shown in
  3069. Table\ 2/X.212.
  3070. .ce
  3071. \fBH.T. [T2.212]\fR 
  3072. .ce
  3073. TABLE\ 2/X.212
  3074. .ce
  3075. \fBClassification of performance QOS parameters\fR 
  3076. .ps 9
  3077. .vs 11
  3078. .nr VS 11
  3079. .nr PS 9
  3080. .TS
  3081. center box;
  3082. cw(180p) .
  3083. Performance criterion  
  3084. _
  3085. .T&
  3086. cw(48p) | cw(132p) .
  3087. Speed    Accuracy reliability
  3088. _
  3089. .T&
  3090. lw(48p) | lw(132p) .
  3091. Throughput transit delay    T{
  3092. Residual error rate (corruption, duplication/loss)
  3093. Resilience
  3094. T}
  3095. _
  3096. .TE
  3097. .nr PS 9
  3098. .RT
  3099. .ad r
  3100. \fBTable [T2.212], p.\fR 
  3101. .sp 1P
  3102. .RT
  3103. .ad b
  3104. .RT
  3105. .LP
  3106.     b)
  3107.      parameters that express other DLS characteristics, as shown in Table\ 
  3108. 3/X.212. 
  3109. .ce
  3110. \fBH.T. [T3.212]\fR 
  3111. .ce
  3112. TABLE\ 3/X.212
  3113. .ce
  3114. \fBQOS parameters not associated with performance\fR 
  3115. .ps 9
  3116. .vs 11
  3117. .nr VS 11
  3118. .nr PS 9
  3119. .TS
  3120. center box;
  3121. cw(48p) .
  3122. Protection Priority
  3123. _
  3124. .T&
  3125. lw(144p) .
  3126. T{
  3127. \fINote\fR
  3128. \ \(em\ Some QOS parameters are defined in terms of the issuance of DLS primitives. Reference to a DLS primitive refers to the complete execution of that DLS primitive at the appropriate DLSAP.
  3129. T}
  3130. .TE
  3131. .nr PS 9
  3132. .RT
  3133. .ad r
  3134. \fBTable [T3.212], p.\fR 
  3135. .sp 1P
  3136. .RT
  3137. .ad b
  3138. .RT
  3139. .sp 1P
  3140. .LP
  3141. 10.2.1
  3142.     \fIThroughput\fR 
  3143. .sp 9p
  3144. .RT
  3145. .PP
  3146. Throughput is defined as the total number of DLSDU bits
  3147. successfully transferred by a DL\(hyDATA request/DL\(hyDATA indication 
  3148. primitive 
  3149. sequence divided by the input/output time for that sequence.
  3150. .PP
  3151. Successful transfer of the bits in a transmitted DLSDU is defined to occur 
  3152. when the bits are delivered to the intended receiving DLS user without 
  3153. error, in the proper sequence, prior to release of the DLC by the receiving 
  3154. DLS user. 
  3155. .PP
  3156. The input/output time for a DL\(hyDATA request/DL\(hyDATA indication
  3157. primitive sequence is the greater of the two times in the following
  3158. list:
  3159. .RT
  3160. .LP
  3161.     a)
  3162.     the time between the first and the last DL\(hyDATA request in   the sequence;
  3163. .LP
  3164.     b)
  3165.      the time between the first and the last DL\(hyDATA indication in the 
  3166. sequence. 
  3167. .PP
  3168. Throughput is only meaningful for a sequence of complete DLSDUs.
  3169. .bp
  3170. .PP
  3171. Throughput is specified independently for each direction of transfer. In 
  3172. general, each throughput specification will define both the desired target 
  3173. value and the minimum acceptable value (or lowest acceptable QOS) for a 
  3174. DLC. 
  3175. Each specification is an average rate and will be based on a previously 
  3176. stated average DLSDU size. 
  3177. .PP
  3178. Either the input or the output of a sequence of DLSDUs may be delayed excessively 
  3179. by the DLS users. Occurrences of delay caused by the DLS users are excluded 
  3180. in calculating average throughput values. 
  3181. .RT
  3182. .sp 1P
  3183. .LP
  3184. 10.2.2
  3185.     \fITransit delay\fR 
  3186. .sp 9p
  3187. .RT
  3188. .PP
  3189. Transit delay is the elapsed time between DL\(hyDATA request
  3190. primitives and the corresponding DL\(hyDATA indication primitives. Elapsed time
  3191. values are calculated only on DLSDUs that are successfully transferred.
  3192. .PP
  3193. Succesful transfer of a DLSDU for the purposes of the QOS parameter is 
  3194. defined to occur when the DLSDU is transferred from the sending DLS user 
  3195. to he intended receiving DLS user without error, and in the proper sequence 
  3196. prior to release of the DLC by the receiving DLS user. 
  3197. .PP
  3198. For connection\(hymode transfer transit delay is specified independently 
  3199. for each direction of transfer. Each specification is based on a previously 
  3200. stated average DLSDU size.
  3201. .PP
  3202. The transit delay for an individual DLSDU may be increased if the
  3203. receiving DLS user exercises interface flow control. Such occurrences are
  3204. excluded in calculating transit delay values.
  3205. .RT
  3206. .sp 1P
  3207. .LP
  3208. 10.2.3
  3209.     \fIResidual Error Rate\fR 
  3210. .sp 9p
  3211. .RT
  3212. .PP
  3213. Residual error rate is the ratio of total incorrect, lost and
  3214. duplicate DLSDUs to total DLSDUs transferred across the DLS boundary during 
  3215. a measurement period. The relationship among these quantities is defined, 
  3216. for a particular DLS user pair, as shown in Figure\ 3/X.212. 
  3217. .RT
  3218. .LP
  3219. .rs
  3220. .sp 12P
  3221. .ad r
  3222. \fBFigure 3/X.212, p.\fR 
  3223. .sp 1P
  3224. .RT
  3225. .ad b
  3226. .RT
  3227. .sp 1P
  3228. .LP
  3229. 10.2.4
  3230.     \fIResilience\fR 
  3231. .sp 9p
  3232. .RT
  3233. .PP
  3234. This parameter specifies the probability of:
  3235. .RT
  3236. .LP
  3237.     a)
  3238.      a DLS provider initiated DLC release (i.e.\ the isuance of a DL\(hyDISCONNECT 
  3239. indication primitive with no prior DL\(hyDISCONECT request 
  3240. primitive); or
  3241. .LP
  3242.     b)
  3243.     a DLS provider initiated reset (i.e.\ the issuance of a
  3244. DL\(hyRESET indication primitive with no prior DL\(hyRESET request primitive);
  3245. .LP
  3246. during a specified time interval on an established DLC.
  3247. .bp
  3248. .sp 1P
  3249. .LP
  3250. 10.2.5
  3251.     \fIProtection\fR 
  3252. .sp 9p
  3253. .RT
  3254. .PP
  3255. Protection is the extent to which a DLS provider attempts to
  3256. prevent unauthorized monitoring or manipulation of DLS user originated
  3257. information. Protection is specified by a minimum and maximum protection 
  3258. option within a range of three possible protection options: 
  3259. .RT
  3260. .LP
  3261.     a)
  3262.     no protection features;
  3263. .LP
  3264.     b)
  3265.     protection against passive monitoring; and
  3266. .LP
  3267.     c)
  3268.     protection against modification, replay, addition or
  3269. deletion.
  3270. .PP
  3271. Within the specified range, a DLS user selects a particular value during 
  3272. DLC establishment. 
  3273. .PP
  3274. Each protection feature addresses a particular type of privacy or
  3275. security threat, and each if available is typically provided by a different 
  3276. DLS provider mechanism. 
  3277. .RT
  3278. .sp 1P
  3279. .LP
  3280. 10.2.6
  3281.     \fIPriority\fR 
  3282. .sp 9p
  3283. .RT
  3284. .PP
  3285. The specification of priority is concerned with the relationship
  3286. between DLCs.
  3287. .PP
  3288. This parameter specifies the relative importance of a DLC with respect to:
  3289. .RT
  3290. .LP
  3291.     a)
  3292.     the order in which DLCs are to have their QOS degraded, if   necessary; and
  3293. .LP
  3294.     b)
  3295.     the order in which DLCs are to be released to recover
  3296. resources, if necessary.
  3297. .PP
  3298. Priority is specified by a minimum and a maximum within a given
  3299. range. Within the specified range, a DLS user selects a particular value 
  3300. during DLC establishment. 
  3301. .PP
  3302. This parameter only has meaning in the context of some management
  3303. entity of structure able to judge relative importance. The number of priority 
  3304. levels is limited. 
  3305. .RT
  3306. .sp 2P
  3307. .LP
  3308. \fB11\fR     \fBSequence of primitives\fR 
  3309. .sp 1P
  3310. .RT
  3311. .sp 1P
  3312. .LP
  3313. 11.1
  3314.     \fIConcepts used to define the connection\(hymode Data Link Service\fR 
  3315. .sp 9p
  3316. .RT
  3317. .PP
  3318. The service definition uses the following concepts:
  3319. .RT
  3320. .LP
  3321.     a)
  3322.      DLC can be dynamically established or terminated between the DLS users 
  3323. for the purpose of exchanging data; 
  3324. .LP
  3325.     b)
  3326.      associated with each DLC, certain measures of QOS that are agreed between 
  3327. the DLS provider and the DLS users when the connection is 
  3328. established;
  3329. .LP
  3330.     c)
  3331.     the DLC allows transmission of data and preserves its
  3332. division into DLSDUs; the transmission of this data is subject to flow
  3333. control;
  3334. .LP
  3335.     d)
  3336.     the DLC can be returned to a defined state, and the
  3337. activities of the two DLS users synchronized by the use of a Reset Service;
  3338. .LP
  3339.     e)
  3340.      failure to provide the requested service may be signalled to the DLS 
  3341. user. There are three classes of failure: 
  3342. .LP
  3343.     1)
  3344.     failures involving termination of the DLC;
  3345. .LP
  3346.     2)
  3347.      failures involving loss or duplication of user data, but without loss 
  3348. of DLC; and 
  3349. .LP
  3350.     3)
  3351.      failures to provide the requested QOS without loss or duplication of 
  3352. user data or loss of the DLC. 
  3353. .sp 1P
  3354. .LP
  3355. 11.2
  3356.     \fIConstraints of Sequence of Primitives\fR 
  3357. .sp 9p
  3358. .RT
  3359. .PP
  3360. This section defines the constraints of the sequence in which the primitives 
  3361. defined in sections\ 12\(hy14 may occur. The constraints determine the 
  3362. order in which primitives occur, but do not fully specify when they may 
  3363. occur. Other constraints, such as flow control of data, will affect the 
  3364. ability of a DLS user or a DLS provider to issue a primitive at any particular 
  3365. time. 
  3366. .PP
  3367. The connection\(hymode primitives and their parameters are summarized in 
  3368. Table\ 4/X.212. 
  3369. .bp
  3370. .RT
  3371. .ce
  3372. \fBH.T. [T4.212]\fR 
  3373. .ce
  3374. TABLE\ 4/X.212
  3375. .ce
  3376. \fBSummary of data\(hylink\(hyconnection\(hymode primitives and
  3377. .ce
  3378. parameters\fR 
  3379. .ps 9
  3380. .vs 11
  3381. .nr VS 11
  3382. .nr PS 9
  3383. .TS
  3384. center box;
  3385. cw(36p) | cw(36p) | cw(72p) | cw(84p) .
  3386. Phase    Service    Primitive    Parameters  
  3387. _
  3388. .T&
  3389. lw(36p) | lw(36p) | lw(72p) | lw(84p) .
  3390. DLC establishment    DLC establishment    DL\(hyCONNECT request    T{
  3391. (Called address,
  3392. calling address, QOS parameter set)
  3393. T}
  3394. .T&
  3395. lw(36p) | lw(36p) | lw(72p) | lw(84p) .
  3396.         DL\(hyCONNECT indication    T{
  3397. (Called address,
  3398. calling address, QOS parameter set)
  3399. T}
  3400. .T&
  3401. lw(36p) | lw(36p) | lw(72p) | lw(84p) .
  3402.         DL\(hyCONNECT response    T{
  3403. (Responding address,
  3404. QOS parameter set)
  3405. T}
  3406. .T&
  3407. lw(36p) | lw(36p) | lw(72p) | lw(84p) .
  3408.         DL\(hyCONNECT confirm    T{
  3409. (Responding address, QOS
  3410. parameter set)
  3411. T}
  3412. .T&
  3413. lw(36p) | lw(36p) | lw(72p) | lw(84p) .
  3414. Data transfer    Normal data transfer    DL\(hyDATA request    (DLS user\(hydata)
  3415. .T&
  3416. lw(36p) | lw(36p) | lw(72p) | lw(84p) .
  3417.         DL\(hyDATA indication    (DLS user\(hydata)
  3418. .T&
  3419. lw(36p) | lw(36p) | lw(72p) | lw(84p) .
  3420.     Reset    DL\(hyRESET request    (Reason)
  3421. .T&
  3422. lw(36p) | lw(36p) | lw(72p) | lw(84p) .
  3423.         DL\(hyRESET indication    (Originator, reason)
  3424. .T&
  3425. lw(36p) | lw(36p) | lw(72p) | lw(84p) .
  3426.         DL\(hyRESET response     
  3427. .T&
  3428. lw(36p) | lw(36p) | lw(72p) | lw(84p) .
  3429.         DL\(hyRESET confirm     
  3430. .T&
  3431. lw(36p) | lw(36p) | lw(72p) | lw(84p) .
  3432. DLC release    DLC release    DL\(hyDISCONNECT request    (Reason) 
  3433. .T&
  3434. lw(36p) | lw(36p) | lw(72p) | lw(84p) .
  3435.         DL\(hyDISCONNECT indication    (Originator reason)
  3436. _
  3437. .TE
  3438. .nr PS 9
  3439. .RT
  3440. .ad r
  3441. \fBTableau 4/X.212 [T4.212], p. 32\fR 
  3442. .sp 1P
  3443. .RT
  3444. .ad b
  3445. .RT
  3446. .LP
  3447. .sp 5
  3448. .sp 1P
  3449. .LP
  3450. 11.2.1
  3451.     \fIRelation of Primitives at the Two Endpoints\fR 
  3452. .sp 9p
  3453. .RT
  3454. .PP
  3455. A primitive issued at one DLC endoint will, in general, have
  3456. consequences at the other DLC endpoint. The relations of primitives of each
  3457. type at one DLC endpoint to primitives at the other DLC endpoint are defined 
  3458. in the appropriate subsections in sections\ 12\(hy15; all these relations 
  3459. are 
  3460. summarized in the diagrams in Figure\ 4/X.212.
  3461. .PP
  3462. However, a DL\(hyDISCONNECT request or indication primitive may terminate 
  3463. any of the other sequences before completion. 
  3464. .bp
  3465. .RT
  3466. .LP
  3467. .rs
  3468. .sp 47P
  3469. .ad r
  3470. \fBFigure 4/X.212, p. 33\fR 
  3471. .sp 1P
  3472. .RT
  3473. .ad b
  3474. .RT
  3475. .LP
  3476. .bp
  3477. .sp 1P
  3478. .LP
  3479. 11.2.2
  3480.     \fISequence of primitives at one DLC endpoint\fR 
  3481. .sp 9p
  3482. .RT
  3483. .PP
  3484. The possible overall sequences of primitives at a DLC endoint are defined 
  3485. in the state transition diagram, Figure\ 5/X.212. In the 
  3486. diagram:
  3487. .RT
  3488. .LP
  3489.     a)
  3490.     DL\(hyDISCONNECT stands for either the request or the
  3491. indication form of the primitive in all cases.
  3492. .LP
  3493.     b)
  3494.     The labelling of the states \*QDLS user initiated reset
  3495. pending\*U (5) and \*QDLS provider initiated reset pending\*U (6) indicate 
  3496. the party that started the local interaction, and does not necessarily 
  3497. reflect the value of the originator parameter. 
  3498. .LP
  3499.     c)
  3500.      The idle state (1) reflects the absence of a DLC. It is the initial and 
  3501. final state of any sequence, and once it has been re\(hyentered, the DLC 
  3502. is released. 
  3503. .LP
  3504.     d)
  3505.     The use of a state transition diagram to describe the
  3506. allowable sequences of service primitives does not impose any requirements 
  3507. or constraints on the internal organization of any implementations of the 
  3508. service.
  3509. .LP
  3510. .rs
  3511. .sp 31P
  3512. .ad r
  3513. \fBFigure 4/X.212, p.\fR 
  3514. .sp 1P
  3515. .RT
  3516. .ad b
  3517. .RT
  3518. .sp 2P
  3519. .LP
  3520. \fB12\fR     \fBConnection establishment phase\fR 
  3521. .sp 1P
  3522. .RT
  3523. .sp 1P
  3524. .LP
  3525. 12.1
  3526.     \fIFunction\fR 
  3527. .sp 9p
  3528. .RT
  3529. .PP
  3530. The connection establishment service primitives can be used to
  3531. establish a DLC.
  3532. .PP
  3533. Simultaneous DL\(hyCONNECT request primitives at the two DLSAPs result 
  3534. in one DLC as indicated in Figure\ 6/X.212. 
  3535. .bp
  3536. .RT
  3537. .sp 1P
  3538. .LP
  3539. 12.2
  3540.     \fITypes of\fR 
  3541. \fIprimitives and parameters\fR 
  3542. .sp 9p
  3543. .RT
  3544. .PP
  3545. Table 5/X.212 indicates the types of primitives and the parameters needed 
  3546. for connection establishment. 
  3547. .RT
  3548. .ce
  3549. \fBH.T. [T5.212]\fR 
  3550. .ce
  3551. TABLE\ 5/X.212
  3552. .ce
  3553. \fBDLC establishment primitives and parameters\fR 
  3554. .ps 9
  3555. .vs 11
  3556. .nr VS 11
  3557. .nr PS 9
  3558. .TS
  3559. center box;
  3560. lw(60p) | cw(42p) | cw(42p) | cw(42p) | cw(42p) .
  3561. T{
  3562. Primitive
  3563. \| \|
  3564. \| \|
  3565. Parameter
  3566. T}    DL\(hyCONNECT request    DL\(hyCONNECT indication    DL\(hyCONNECT response    DL\(hyCONNECT confirm  
  3567. _
  3568. .T&
  3569. lw(60p) | cw(42p) | cw(42p) | cw(42p) | cw(42p) .
  3570. Called address    X    X(=) (see Note\ 2)        
  3571. _
  3572. .T&
  3573. lw(60p) | cw(42p) | cw(42p) | cw(42p) | cw(42p) .
  3574. Calling address    X (see Note\ 2)    X(=)        
  3575. _
  3576. .T&
  3577. lw(60p) | cw(42p) | cw(42p) | cw(42p) | cw(42p) .
  3578. Responding address            X (see Notes\ 1, 2)    X(=)\fR
  3579. _
  3580. .T&
  3581. lw(60p) | cw(42p) | cw(42p) | cw(42p) | cw(42p) .
  3582. T{
  3583. Quality of service parameter set
  3584. T}    X    X    X    T{
  3585. X
  3586. \fINote\ 1\fR
  3587. \ \(em\ The need for responding address parameter if for further
  3588. study.
  3589. .parag
  3590. \fINote\ 2\fR
  3591. \ \(em\ This parameter may be implicitly associated with the DLSAP at
  3592. which the primitive is issued.
  3593. .parag
  3594. T}
  3595. _
  3596. .TE
  3597. .nr PS 9
  3598. .RT
  3599. .ad r
  3600. \fBTable [T5.212], p.\fR 
  3601. .sp 1P
  3602. .RT
  3603. .ad b
  3604. .RT
  3605. .sp 1P
  3606. .LP
  3607. .sp 2
  3608. 12.2.1
  3609.     \fIAddresses\fR 
  3610. .sp 9p
  3611. .RT
  3612. .PP
  3613. The parameters which take addresses as values (see
  3614. \(sc\(sc\ 12.2.2\(hy12.2.4) all refer to DLSAP addresses.
  3615. .PP
  3616. \fINote\fR \ \(em\ If the configuration allows any of these addresses to be
  3617. known by the DL Entity on an \fIa\ priori\fR basis, then these DLSAP address(es) 
  3618. need not eplicitly be conveyed in the protocol.
  3619. .RT
  3620. .sp 1P
  3621. .LP
  3622. 12.2.2
  3623.     \fICalled Address\fR 
  3624. .sp 9p
  3625. .RT
  3626. .PP
  3627. The called address parameter conveys an address identifying the
  3628. DLSAP to which the DLC is to be established.
  3629. .RT
  3630. .sp 1P
  3631. .LP
  3632. 12.2.3
  3633.     \fICalling Address\fR 
  3634. .sp 9p
  3635. .RT
  3636. .PP
  3637. The calling address parameter conveys the address of the DLSAP from which 
  3638. the DLC has been requested. 
  3639. .RT
  3640. .sp 1P
  3641. .LP
  3642. 12.2.4
  3643.     \fIResponding Address\fR 
  3644. .sp 9p
  3645. .RT
  3646. .PP
  3647. The responding address parameter conveys the address of the DLSAP to which 
  3648. the DLC has been established. 
  3649. .RT
  3650. .sp 1P
  3651. .LP
  3652. 12.2.5
  3653.     \fIQuality of Service parameter set\fR 
  3654. .sp 9p
  3655. .RT
  3656. .PP
  3657. The use of the QOS parameter selection is not required when only
  3658. one level of QOS is offered by the DLS provider.
  3659. .bp
  3660. .RT
  3661. .sp 1P
  3662. .LP
  3663. 12.2.5.1
  3664.     \fIThroughput\fR 
  3665. .sp 9p
  3666. .RT
  3667. .PP
  3668. Two quality of service sub\(hyparameters \*Qtarget\*U and \*Qlowest quality 
  3669. acceptable\*U, which are in the agreed range, are passed to the DLS provider 
  3670. in the CONNECT request primitive. THE DLS provider will indicate to the 
  3671. DLS users, the \*Qavailable\*U throughput in the DL\(hyCONNECT confirm, 
  3672. and DL\(hyCONNECT 
  3673. indication. The \*Qavailable\*U parameter shall be a value from the range 
  3674. between the \*Qtarget\*U and \*Qlowest quality acceptable\*U (see \(sc\ 
  3675. 10.2.1). 
  3676. .RT
  3677. .sp 1P
  3678. .LP
  3679. 12.2.5.2
  3680.     \fISelected protection\fR 
  3681. .sp 9p
  3682. .RT
  3683. .PP
  3684. The parameter specifies a particular degree of protection, within the agreed 
  3685. range (see \(sc\ 10.2.5) for the DLSDU of any subsequently submitted 
  3686. DL\(hyDATA request primitive transferred on the DLC.
  3687. .RT
  3688. .sp 1P
  3689. .LP
  3690. 12.2.5.3
  3691.     \fISelected priority\fR 
  3692. .sp 9p
  3693. .RT
  3694. .PP
  3695. The parameter specifies a particular priority, within the agreed
  3696. range (see \(sc\ 10.2.6), for the DLSDU of any subsequent DL\(hyDATA request 
  3697. primitive transferred on the DLC. 
  3698. .RT
  3699. .sp 1P
  3700. .LP
  3701. 12.3
  3702.     \fISequence of primitives\fR 
  3703. .sp 9p
  3704. .RT
  3705. .PP
  3706. The sequence of primitives in a successful connection establishment is 
  3707. defined by the time\(hysequence diagram in Figure\ 6/X.212. 
  3708. .RT
  3709. .LP
  3710. \fR .rs
  3711. .sp 16P
  3712. .ad r
  3713. \fBFigure 6/X.212, p.\fR 
  3714. .sp 1P
  3715. .RT
  3716. .ad b
  3717. .RT
  3718. .PP
  3719. These DLC establishment procedures may fail either due to the
  3720. inability of the DLS provider to establish a DLC or due to the unwillingness 
  3721. of the called DLS user to accept a DL\(hyCONNECT indication primitive (for 
  3722. these 
  3723. cases see DLC release service, \(sc\(sc\ 13.4 and\ 13.5).
  3724. .sp 2P
  3725. .LP
  3726. \fB13\fR     \fBConnection release phase\fR 
  3727. .sp 1P
  3728. .RT
  3729. .sp 1P
  3730. .LP
  3731. 13.1
  3732.     \fIFunction\fR 
  3733. .sp 9p
  3734. .RT
  3735. .PP
  3736. The connection release service primitives are used to release a
  3737. DLC. The release may be initiated by any of the following:
  3738. .RT
  3739. .LP
  3740.     a)
  3741.     either or both of the DLS users, to release an established   DLC;
  3742. .LP
  3743.     b)
  3744.     the DLS providers to release an established DLC; all
  3745. failures to maintain a DLC are indicated in this way;
  3746. .LP
  3747.     c)
  3748.     the DLS user, to reject a DL\(hyCONNECT indication;
  3749. .LP
  3750.     d)
  3751.     the DLS provider, to indicate its inability to establish a   requested DLC; or
  3752. .LP
  3753.     e)
  3754.      the DLS user which sent the DL\(hyCONNECT request, to abandon the connection 
  3755. attempt before the connection has been made available for use by receipt 
  3756. of a DL\(hyCONNECT primitive. 
  3757. .bp
  3758. .PP
  3759. Initiation of the release service element is permitted at any time regardless 
  3760. of the current phase of the DLC. Once a release service has been 
  3761. initiated, the DLC will be disconnected. A DL\(hyDISCONNECT request cannot be
  3762. rejected. The DLS does not guarantee delivery of any DLSDU associated with 
  3763. the DLC once the release phase is entered. 
  3764. .sp 1P
  3765. .LP
  3766. 13.2
  3767.     \fITypes of primitive and parameters\fR 
  3768. .sp 9p
  3769. .RT
  3770. .PP
  3771. Table 6/X.212 indicated the types of primitives and the parameters needed 
  3772. for connection release. 
  3773. .RT
  3774. .ce
  3775. \fBH.T. [T6.212]\fR 
  3776. .ce
  3777. TABLE\ 6/X.212
  3778. .ce
  3779. \fBDLC release primitives and parameters\fR 
  3780. .ps 9
  3781. .vs 11
  3782. .nr VS 11
  3783. .nr PS 9
  3784. .TS
  3785. center box;
  3786. lw(78p) | cw(78p) | cw(72p) .
  3787. Primitive Parameter      DL\(hyDISCONNECT request      DL\(hyDISCONNECT indication
  3788. _
  3789. .T&
  3790. lw(78p) | cw(78p) | cw(72p) .
  3791. Originator        X
  3792. _
  3793. .T&
  3794. lw(78p) | cw(78p) | cw(72p) .
  3795. Reason    X    
  3796. _
  3797. .TE
  3798. .nr PS 9
  3799. .RT
  3800. .ad r
  3801. \fBTable [T6.212], p.\fR 
  3802. .sp 1P
  3803. .RT
  3804. .ad b
  3805. .RT
  3806. .sp 1P
  3807. .LP
  3808. 13.2.1
  3809.     \fIOriginator\fR 
  3810. .sp 9p
  3811. .RT
  3812. .PP
  3813. The originator parameter indicates the source of the release. Its value 
  3814. indicates either the DLS user, the DLS provider, or that the originator 
  3815. is unkown. 
  3816. .RT
  3817. .sp 1P
  3818. .LP
  3819. 13.2.2
  3820.     \fIReason\fR 
  3821. .sp 9p
  3822. .RT
  3823. .PP
  3824. The reason parameter gives information about the cause of the
  3825. release. The value conveyed in this parameter will be as follows:
  3826. .RT
  3827. .LP
  3828.     a)
  3829.     when the originator parameter indicates a DLS provider
  3830. generated release, the value is one of:
  3831. .LP
  3832.     1)
  3833.     \*Qdisconnection\(hypermanent condition\*U;
  3834. .LP
  3835.     2)
  3836.     \*Qdisconnection\(hytransient condition\*U;
  3837. .LP
  3838.     3)
  3839.     \*Qconnection rejection\(hyDLSAP\(hyaddress unknown\*U;
  3840. .LP
  3841.     4)
  3842.     \*Qconnection rejection\(hyDLSAP unreachable/permanent
  3843. condition\*U;
  3844. .LP
  3845.     5)
  3846.     \*Qconnection rejection\(hyDLSAP unreachable/transient
  3847. condition\*U;
  3848. .LP
  3849.     6)
  3850.     \*Qconnection rejection\(hyQOS not available/permanent
  3851. condition\*U;
  3852. .LP
  3853.     7)
  3854.     \*Qconnection rejection\(hyQOS not available/transient
  3855. condition\*U; or
  3856. .LP
  3857.     8)
  3858.     \*Qreason unspecified\*U;
  3859. .LP
  3860.      \fINote\fR \ \(em\ Addition to, or refinement of this list of values 
  3861. to convey more specific diagnostic and management information is for further 
  3862. study.
  3863. .LP
  3864.     b)
  3865.      when the originator parameter indicates DLS user initiated release, the 
  3866. value is one of: 
  3867. .LP
  3868.     1)
  3869.     \*Qdisconnection\(hynormal condition\*U;
  3870. .LP
  3871.     2)
  3872.     \*Qdisconnection\(hyabnormal condition\*U;
  3873. .LP
  3874.     3)
  3875.     \*Qconnection rejection\(hypermanent condition\*U;
  3876. .LP
  3877.     4)
  3878.     \*Qconnection rejection\(hytransient condition\*U; or
  3879. .LP
  3880.     5)
  3881.     \*Qreason unspecified\*U; and
  3882. .LP
  3883.     c)
  3884.     when the originator parameter indicates an unknown
  3885. originator the value of the Reason parameter is \*Qreason unspecified\*U. This
  3886. allows the parameters to be implied when they cannot be explicitly conveyed 
  3887. in the Data Link protocol. 
  3888. .bp
  3889. .sp 1P
  3890. .LP
  3891. 13.3
  3892.     \fISequence of primitives when releasing an established DLC\fR 
  3893. .sp 9p
  3894. .RT
  3895. .PP
  3896. The sequence of primitives depends on the origins of the release
  3897. action. The sequence may be:
  3898. .RT
  3899. .LP
  3900.     a)
  3901.      initiated by one DLS user, with a request from that DLS user leading 
  3902. to an indication to the other; 
  3903. .LP
  3904.     b)
  3905.     initiated by both DSL users, with a request from each of the DLS users;
  3906. .LP
  3907.     c)
  3908.     initiated by the DLS provider, with an indication to each of the DLS users; or
  3909. .LP
  3910.     d)
  3911.     initiated independently by one DLS user and the DLS
  3912. provider, with a request from the originating DLS user and an indication 
  3913. to the other. 
  3914. .PP
  3915. The sequences of primitives in these four cases are defined by the time\(hysequence 
  3916. diagrams in Figures\ 7/X.212\(hy10/X.212. 
  3917. .LP
  3918. .rs
  3919. .sp 10P
  3920. .ad r
  3921. \fBFigure 7/X.212, p. 38\fR 
  3922. .sp 1P
  3923. .RT
  3924. .ad b
  3925. .RT
  3926. .LP
  3927. .rs
  3928. .sp 10P
  3929. .ad r
  3930. \fBFigure 8/X.212, p. 39\fR 
  3931. .sp 1P
  3932. .RT
  3933. .ad b
  3934. .RT
  3935. .LP
  3936. .rs
  3937. .sp 10P
  3938. .ad r
  3939. \fBFigure 9/X.212, p. 40\fR 
  3940. .sp 1P
  3941. .RT
  3942. .ad b
  3943. .RT
  3944. .LP
  3945. .bp
  3946. .LP
  3947. .rs
  3948. .sp 8P
  3949. .ad r
  3950. \fBFigure 10/X.212, p. 41\fR 
  3951. .sp 1P
  3952. .RT
  3953. .ad b
  3954. .RT
  3955. .LP
  3956. .rs
  3957. .sp 10P
  3958. .ad r
  3959. \fBFigure 11/X.212, p. 42\fR 
  3960. .sp 1P
  3961. .RT
  3962. .ad b
  3963. .RT
  3964. .LP
  3965. .rs
  3966. .sp 10P
  3967. .ad r
  3968. \fBFigure 12/X.212, p. 43\fR 
  3969. .sp 1P
  3970. .RT
  3971. .ad b
  3972. .RT
  3973. .LP
  3974. .rs
  3975. .sp 8P
  3976. .ad r
  3977. \fBFigure 13/X.212, p. 44\fR 
  3978. .sp 1P
  3979. .RT
  3980. .ad b
  3981. .RT
  3982. .LP
  3983. .bp
  3984. .LP
  3985. .rs
  3986. .sp 11P
  3987. .ad r
  3988. \fBFigure 14/X.212, p. 45\fR 
  3989. .sp 1P
  3990. .RT
  3991. .ad b
  3992. .RT
  3993. .LP
  3994. .rs
  3995. .sp 13P
  3996. .ad r
  3997. \fBFigure 15/X.212, p. 46\fR 
  3998. .sp 1P
  3999. .RT
  4000. .ad b
  4001. .RT
  4002. .sp 1P
  4003. .LP
  4004. 13.4
  4005.     \fISequence of primitives in a DLS user rejection of DLC\fR 
  4006. \fIestablishment attempt\fR 
  4007. .sp 9p
  4008. .RT
  4009. .PP
  4010. A DLS user may reject a DLC establishment attempt by using a
  4011. DL\(hyDISCONNECT request. The originator parameter in the DL\(hyDISCONNECT 
  4012. primitives will indicate DLS user initiated release. The sequence of events 
  4013. is defined in the time\(hysequence diagram in Figure\ 11/X.212. 
  4014. .RT
  4015. .sp 1P
  4016. .LP
  4017. 13.5
  4018.     \fISequence of primitives in a DLS provider rejection of a DLC\fR 
  4019. \fIestablishment attempt\fR 
  4020. .sp 9p
  4021. .RT
  4022. .PP
  4023. If the DLS provider is unable to establish a DLC, it indicates this to 
  4024. the requester by a DL\(hyDISCONNECT indication. The originator parameter 
  4025. in 
  4026. this primitive indicates a DLS provider originated release. The sequence of
  4027. events is defined in the time\(hysequence diagram in Figure\ 12/X.212.
  4028. .RT
  4029. .sp 1P
  4030. .LP
  4031. 13.6
  4032.      \fISequence of Primitives in a DLS User Abort of a DLC Establishment\fR 
  4033. \fIAttempt\fR 
  4034. .sp 9p
  4035. .RT
  4036. .PP
  4037. If the DLS user, having previously sent a DL\(hyCONNECT request and
  4038. not received a DL\(hyCONNECT confirm or DL\(hyDISCONNECT indication, wishes 
  4039. to abort the DLC establishment attempts the DLS user shall issue a DL\(hyDISCONNECT 
  4040. request. The resulting sequence of primitives is dependent upon the relative
  4041. timing of the primitives involved and the transit delay of the DLS provider 
  4042. as defined by the time\(hysequence diagrams in Figures\ 13/X.212 to\ 15/X.212. 
  4043. No 
  4044. information can be implied by detecting which of these alternatives occur.
  4045. .RT
  4046. .LP
  4047. .bp
  4048.